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The  present  volume  contains  the  invited  papers  presented  at  the  seventh 
annual  Clinic  on  Library  Applications  of  Data  Processing  held  April  27-30, 
1969,  at  Urbana  by  the  Division  of  University  Extension  and  the  Graduate 
School  of  Library  Science  of  the  University  of  Illinois. 

This  year,  following  the  keynote  paper  by  Foster  Palmer  of  Harvard 
University  Library,  accounts  and  analyses  of  actual  operational  library  case 
experience  were  presented  by  Robert  A.  Kennedy  (for  the  Bell  Laboratories 
Library  System),  Thomas  K.  Burgess  (for  Washington  State  University 
Library),  T.  C.  Dobb  (for  Simon  Fraser  University  Library),  John  B.  Corbin 
(for  Tarrant  County  Junior  College  District  Libraries,  Fort  Worth,  Texas),  and 
Calvin  J.  Boyer  and  Jack  Frost  (for  Midwestern  University  Library).  Progress 
reports  on  major  research  and  developmental  efforts  were  also  presented  by 
Ann  T.  Curran  (for  the  New  England  Library  Information  Network),  Ben-Ami 
Lipetz  (for  Yale  University  Library),  and  Stephen  R.  Salmon  (for  the  Library 
of  Congress).  In  addition,  two  papers  considering  PL/I  as  a  programming 
language  from  the  vantage  point  of  actual  library  applications  were  given  by 
James  L.  Ames  (for  Washington  State  University  Library)  and  Betty  Snell  (for 
Simon  Fraser  University  Library). 

Because  of  unforeseen  circumstances,  the  announced  paper  by  Richard 
Hirsch  on  the  generalized  on-line  library  system  at  the  IBM  Advanced  Systems 
Development  Division  (Los  Gatos)  could  not  be  incorporated  in  the  present 
volume.  Hirsch's  place  at  the  Clinic  was  filled  very  ably,  however,  by  his 
colleague,  Charles  Hoppel,  who  gave  an  in-depth  review  of  the  progress  at 
IBM's  Los  Gatos  laboratories  which  augurs  well  for  future  developments  in 
library  automation. 

Like  previous  volumes  of  the  Proceedings,  the  present  papers  continue 
to  reflect  major  advances  in  both  the  extent  and  the  sophistication  of  the 
application  of  data  processing  technology  in  all  areas  of  library  operations. 
Discerning  readers  will  note  that  the  promise  of  on-line  systems  has  already 
begun  to  materialize  and  that  we  are  now  addressing  ourselves  to  questions 
concerning  details  and  to  optimal  "mixes"  of  various  on-line  and  batch 
processing  applications.  The  truth  and  impact  of  the  latter  observation  were 
underscored  for  all  who  attended  the  Clinic,  not  only  by  the  masterful 
accounts  of  Robert  Kennedy,  Charles  Hoppel,  and  others  who  enjoy  the 
utilization  of  larger  third  generation  hardware  systems,  but  also  by  the  highly 
entertaining  as  well  as  informative  report  of  the  imaginative  exploitation  of 
smaller  second  generation  computers  by  Calvin  Boyer  and  Jack  Frost. 

It  is  a  real  pleasure,  finally,  to  acknowledge  the  cooperative  support  of 
other  members  of  the  faculty  and  staff  who  contributed  to  this  most 
successful  1969  Clinic:  Robert  B.  Downs,  Herbert  Goldhor,  and  Frances  B. 
Jenkins  of  the  faculty  of  the  Graduate  School  of  Library  Science;  Timothy 
Sineath,  "emeritus"  liaison  representative  with  the  Division  of  University 
Extension,  and  his  successor  Susan  Holty;  and  Robert  D.  Kozlow,  Automation 
Librarian  of  the  University  of  Illinois. 

Dewey  D.  Carroll 

Urbana,  Illinois  Clinic  Chairman  and  Editor 

October  1969 
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A  LIBRARIAN'S  VIEW  OF  DATA  PROCESSING 

Choosing  a  title  for  this  paper  five  months  before  it  was  to  be  given  was 
something  of  a  problem.  Knowing  I  had  the  broad  field  of  library  applications 
of  data  processing  to  discuss  added  to  the  number  of  possibilities.  "Testa- 
ment," however,  seemed  too  final;  "confessions"  seemed  too  lurid— finally  I 
settled  on  "view."  However,  one's  view  may  change,  depending  on  the  view- 
point, and,  in  fact,  I  will  offer  not  a  single  view  but  three.  First  I  will  discuss 
the  rather  expansive  experimental  days  of  the  MARC  Project,  then  the  prob- 
lems of  getting  an  actual  daily  production  job  on  the  road,  and  finally,  in  a 
different  vein,  I  will  present  some  ideas  on  possible  future  systems. 

Since  all  three  are  really  personal  views,  I  should  explain  that  the 
speaker  is  an  old  reference  librarian,  with  considerable  background  in  circula- 
tion. He  knows  the  catalog  fairly  well,  but  as  a  consumer  rather  than  a  pro- 
ducer. He  has  no  personal  experience  in  library  acquisitions  work,  although  he 
has  managed  to  acquire  a  rather  large  personal  collection.  Like  most  librarians, 
he  is  more  a  practitioner  than  a  theoretician.  His  machine  background  came 
late,  via  circulation  and  punched  cards;  he  got  his  start  with  computers  at  the 
University  of  Illinois  not  quite  five  years  ago  from  Kern  Dickman  and  Hillis 
Griffin.  His  first  actual  computer  job  was  to  prepare  the  initial  systems  design 
and  programs  for  the  Widener  Library  shelfist  series  (the  early  volumes,  all  in 
upper  case).1  In  mid-1966  he  was  freed  from  departmental  duties  so  that  he 
could  work  full  time  in  the  field  of  library  automation,  starting  with  the 
Library  of  Congress  MARC  Pilot  Project,  in  which  Harvard  was  one  of  the 
sixteen  selected  participants. 

It  would  be  hard  to  overestimate  the  stimulus  which  the  MARC  Project 
provided  to  the  library  community  in  general  and  the  Harvard  University 
Library  in  particular.  Conditions  at  Harvard  were  propitious.  An  8K  IBM  1401 
with  four  tape  drives  and  upper  and  lower  case  printing  capability  had 
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recently  been  placed  in  the  Library  as  a  substation  of  the  Harvard  Computing 
Center.  If  in  1969  this  seems  like  a  small  and  old-fashioned  piece  of  equip- 
ment, remember  that  the  year  was  1966.  At  that  time  the  dominant  theme  in 
the  news  concerning  third  generation  computers  was  slippage  of  software 
support.  Even  now  I  am  not  willing  to  concede  that  the  1401  was  or  is  a  poor 
thing,  and  it  was  indeed  our  own— not  fiscally,  for  we  paid  by  the  hour,  or,  to 
be  more  exact,  by  the  hundredth  of  an  hour,  but  freely  available  for  hands-on 
use  with  only  mild  competition  even  in  prime  time.  The  budget  for  machine 
usage  was  of  course  not  unlimited,  but  a  generous  allowance  was  made  for 
experimental  use  because  the  administration  of  the  Library  placed  a  high  value 
on  the  long  term  potential  worth  of  the  MARC  Project.  I  do  not  intend  to 
repeat  here  the  description  of  Harvard's  participation  which  appears  in  the 
Library  of  Congress's  published  report.2  Rather,  I  will  try  to  convey  what  it 
means  to  operate  in  an  experimental,  developmental  hands-on  environment 
with  a  computer  with  which  one  feels  at  ease. 

If  one  had  an  idea,  it  was  easy  to  try  it  out  on  the  spot.  No  sending  of 
jobs  to  the  computing  center  by  messenger,  waiting  to  get  them  back  the  next 
day,  telephoning  if  they  did  not  come,  sometimes  getting  them  back  with 
cryptic  messages  indicating  that  they  had  not  run  but  giving  only  the  faintest 
of  clues  why,  with  the  prospect  of  going  through  the  whole  cycle  again  and 
again  as  problems  were  solved  one  by  one.  With  the  computer  right  in  the 
Library,  when  something  went  wrong  (and  of  course  it  often  did),  the  author 
of  the  program  was  right  there  to  evaluate  the  problem.  When  the  dread  red 
light  "process"  appeared  on  the  computer,  sometimes  a  similar,  although 
figurative  light  would  be  the  response  by  the  operator  when  the  address  at 
which  the  program  hung  up  was  compared  with  the  program  listing.  If  not,  at 
least  there  had  been  an  opportunity  to  observe  the  sequence  of  events  leading 
to  the  crash.  Had  this  tape  moved?  What  had  been  written  on  that  one? 
Would  it  be  worthwhile  to  print  out  the  contents  of  the  computer  memory? 
(I  do  not  know  how  many  of  you  have  seen  one  of  these  arcane  documents— a 
printout  showing  exactly  what  is  in  each  position  of  the  computer  memory  at 
a  given  time.  Baffling  to  the  novice,  it  soon  becomes  an  extremely  helpful  aid 
in  finding  program  "bugs.")  Such  a  printout  for  the  1401  would  cost  only  a 
matter  of  cents  anyway.  Contrast  the  situation  with  a  closed  shop  and  a  large 
computer  whose  storage  printout  is  inherently  more  expensive  (because  the 
much  larger  memory  takes  longer  to  print  and  the  cost  per  minute  of  the 
larger  machine  is  much  higher).  One  has  the  option  of  specifying  in  advance 
that  the  printout  be  made  whenever  there  is  a  problem,  and  perhaps  over  a 
period  of  time  accumulating  several  of  the  expensive  documents,  only  one  of 
which  may  turn  out  actually  to  be  useful,  or  skipping  the  option  and  failing 
to  get  the  record  of  the  memory  the  one  time  it  would  have  saved  hours  of 
looking  for  a  needle  in  a  haystack.  (Of  course  storage  printouts  can  also  be 
haystacks,  but  in  a  hands-on  situation  one  at  least  has  a  better  idea  of  when 
the  printout  is  likely  to  be  helpful  or  essential.) 

With  a  machine  in  house,  it  was  often  possible  to  be  back  on  it  minutes 
after  the  problem  was  solved,  rather  than  the  next  day.  All  this  is  not  said  to 
make  a  virtue  of  necessity  and  extol  small  machines  as  such,  but  to  call 
attention  to  the  advantages  of  close  contact  with  the  computer.  For  economic 


A  LIBRARIAN'S  VIEW  OF  DATA  PROCESSING  3 

and  administrative  reasons  such  contact  is  not  likely  to  be  feasible  with  a 
monolithic  large  machine;  whether  time  sharing  with  remote  consoles  really 
makes  it  possible  to  have  the  best  of  both  worlds  you  will  have  to  learn  from 
someone  else  who  has  actual  experience  with  it. 

We  anticipated,  rightly,  a  great  deal  of  nonce  or  ad  hoc  programming  in 
conjunction  with  the  MARC  tapes,  and  to  facilitate  this  prepared  a  whole 
family  of  macro  instructions— another  term  that  may  require  some  explana- 
tion. Each  computer  has  a  built-in  set  of  instructions.  Using  as  we  did  a  low 
level  assembly  language,  normally  each  instruction  written  by  the  programmer 
was  the  equivalent  of  one  machine  instruction.  However,  it  is  possible  to 
gather  together  a  series  of  instructions  that  may  be  useful  on  some  other 
occasion,  give  them  a  name,  put  them  on  the  system  tape  used  in  assembling 
programs,  and  thereafter  call  them  forth  at  will  by  the  name  given.  If  desired, 
parameters— values  appropriate  to  the  particular  use  of  the  moment— may  be 
inserted.  Such  macros  are  an  intermediate  step  in  the  direction  of  a  higher 
level  language  such  as  COBOL  or  PL/I. 

The  term  "family"  was  used  advisedly  in  speaking  of  our  group  of  thirty 
or  so,  since  many  of  the  macros  referred  to  other  macros,  especially  to  a  sort 
of  master  one  called  BEGIN.  The  description  of  macro  capability  in  the  hand- 
book on  the  Autocoder  system  which  we  used  for  assembling  programs 
specified  that  labels  within  macros  in  this  language  should  begin  with  a  right 
parenthesis.  However,  we  discovered  by  experimentation  that  ordinary  alpha- 
numeric labels  could  also  be  used.  This  was  an  essential  factor  in  the  tran- 
sition from  a  series  of  individual  routines  to  an  interlinked  family  or  system. 
For  example,  by  providing  suitable  areas  named  LNCTR  (line  counter)  and 
PGNO  (page  number)  in  the  master  macro  BEGIN,  any  of  the  several  line 
printing  or  page  formatting  macros  could  increment  these  counters  at  will. 
They  could  test  LNCTR  to  see  if  the  page  was  full  (page  length  in  lines,  if 
other  than  the  standard  fifty-eight  provided  by  the  macro,  being  specified  by 
a  parameter).  They  could  test  PGNO  to  see  whether  an  upper  or  lower  page 
(the  fanfold  equivalents  of  verso  and  recto)  was  being  printed  and  adjust  top 
and  bottom  spacing  accordingly,  or  arrange  to  start  a  new  section  on  the 
equivalent  of  a  recto. 

Getting  the  paper  started  right  in  the  first  place  was  the  job  of  another 
very  simple  macro  which  printed  a  message  to  the  operator.  It  would  seem 
that  a  technology  which  can  send  men  around  the  moon  could  devise  some 
sort  of  a  sensing  finger  for  fanfold  forms  which  could  detect  whether  an 
external  or  internal  fold  had  passed  more  recently  and  set  a  program-accessible 
indicator  accordingly,  but  demand  for  this  humble  but  useful  device  has  so  far 
been  insufficient.  In  fact,  operators  from  the  scientific  world  of  the  com- 
puting center  usually  seem  surprised  that  we  care  which  page  we  start  on; 
administrative  and  business  data  processing  types  do  understand  and  that  is 
one  subsidiary  reason  they  typically  send  people  called  data  controllers  along 
with  their  jobs.  In  addition  to  more  weighty  matters  such  as  keeping  straight 
which  tape  is  the  new  master  and  just  what  data  it  incorporates,  they  see  that 
the  forms  are  set  up  correctly. 

As  you  may  have  gathered,  I  am  rather  fond  of  the  1401,  the  DC -3  of 
computers.  Much  of  its  tremendous  success  in  my  opinion  stemmed  from  the 
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fact  that  it  is  an  accessible  machine,  easy  to  learn  without  a  doctorate  in 
computer  science.  One  of  its  less  lovable  features,  however,  is  the  fact  that 
whenever  the  1 20-character  print  chain  is  mounted,  the  distinctive  character 
associated  with  the  termination  of  a  reading  or  writing  of  magnetic  tape 
changes  from  a  group  mark  to  a  tape  mark.  People  far  more  experienced  in 
the  computer  world  than  our  group  was  have  come  to  grief  over  this  little 
fact,  and  coping  with  it  was  an  important  feature  of  our  system  of  macros.  A 
position  labelled  GORTM  contained  either  a  group  mark  word  mark  or  a  tape 
mark  word  mark,  depending  on  which  print  chain  was  mounted.  This  could 
then  be  moved  to  wherever  a  tape  stopper  or  a  test  character  was  desired. 

No  doubt  this  is  more  than  you  want  or  anyone  wants  to  know  about  an 
obsolescent  machine.  The  point  is  that  we  had  our  own  environment,  limited 
though  it  might  have  been,  and  we  learned  to  live  comfortably  in  it  for  that 
time  by  developing  our  own  aids.  Even  if  you  have  the  latest,  largest 
computer,  do  not  underestimate  the  effect  the  peculiarities  of  the  exact  con- 
figuration and  the  operating  system  will  have  on  your  work,  both  for  good 
and  ill— mostly  the  latter  when  it  comes  to  exchanging  programs  with  other 
institutions. 

Any  macros  mentioned  so  far  are  quite  general,  with  no  particular 
orientation  to  libraries.  A  somewhat  more  specialized  one  divided  streams  of 
continuous  text  into  lines  at  word  breaks  or,  optionally,  at  hyphens.  It  did 
not  supply  hyphenation  to  words,  a  tremendously  more  sophisticated  task 
calling  for  a  large  computer  and  great  expertise  in  computer  science  as  well  as 
linguistics.  A  macro  that  was  never  completed  started  with  centering  a  line  on 
a  page,  not  too  difficult  a  problem.  However,  it  got  bogged  down  in  the 
process  of  expansion  to  a  generalized  title  page  layout  routine  incorporating 
judgments  involving  aesthetics  and  psychology.  One  tentative  lesson  from  this 
effort  I  will  record.  If  some  lines  are  an  even  number  of  characters  and  others 
are  odd  it  is  impossible  to  center  them  all  perfectly  in  relation  to  each  other, 
therefore  the  longest  line  should  have  the  half  space  excess  to  the  right. 

There  were  other  macros  to  move  characters  and  provide  for  the  over- 
printing of  diacritics  whenever  necessary  (but  not  slowing  down  the  printer  to 
do  so  when  there  were  none).  Table  macros  to  convert  MARC  or  our  own 
shelflist  character  codes  to  those  giving  the  best  available  output  from  each  of 
three  print  chains  were  also  more  library  related.  The  longest  and  also  most 
specific  to  libraries  was  NAMES,  which  derived  sort  keys  from  personal 
names;  this  work  is  discussed  more  fully  in  the  MARC  report  already  men- 
tioned.2 

Work  with  selection  of  MARC  records  as  well  as  name  and  title  indexing 
is  recounted  in  that  report  and  will  not  be  further  detailed  here,  except  to  say 
that  toward  the  end,  when  the  data  filled  two  and  a  fraction  tapes,  not  lightly 
to  be  run  through,  most  searches  were  multiple.  That  is,  several  things  were 
being  looked  for  during  the  same  run,  and  appropriate  indicators  were  being 
put  in  different  locations  in  the  local  use  field,  recording  which  particular 
set(s)  of  criteria  the  record  met.  Another  development  too  late  to  be  men- 
tioned in  the  printed  report  was  a  limited  error  correction  program.  This  did 
not  reach  the  level  of  changing  the  length  of  fields  or  records,  but  could 
change  lower  case  to  capitals  or  vice  versa  (the  latter  actually  the  commonest 
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correction  required),  or  change  any  character  in  a  specified  location  to  any 
other  character.  A  good  number  of  observed  or  program-detectable  errors  were 
corrected  in  Harvard's  final  MARC  master  by  this  program,  but  we  learned 
that  batch  processing  correction  of  this  type  is  tedious  and  expensive,  even 
though  we  were  prudent  enough  to  select  and  transfer  the  records  to  be 
corrected  onto  a  short  special  tape  which  was  then  passed  several  times  until 
letter  perfect.  Any  thought  that  all  corrections  could  have  been  done  in  one 
pass  through  the  whole  master  would  have  been  wildly  illusory.  Even  if  the 
program  had  had  the  capacity  to  make  as  many  changes  in  one  pass  as  a  few 
of  the  records  required,  human  error  in  specifying  some  of  the  changes  would 
have  spoiled  the  job.  As  happens  with  conventional  proofreading  and  type- 
setting, new  errors  are  easy  to  introduce  while  changes  are  being  made.  For 
example,  the  correct  character  is  moved  to  the  spot  next  to  the  one  to  be 
corrected,  leaving  two  wrongs  instead  of  one.  On-line  capability  seems 
especially  attractive  for  editing  and  error  correction.  It  would  certainly  save 
human  (and  elapsed)  time,  though  higher  machine  costs  might  prove  to  eat  up 
much  or  all  of  the  saving  in  salaries. 

Tedious  as  it  may  have  been  making  corrections  with  this  rather 
primitive  program,  inspecting  a  printout,  and  making  further  corrections,  it 
was  far  simpler  than  it  would  have  been  if  each  pass  had  had  to  be  submitted 
to  a  closed-door  computer  in  another  building.  Had  this  been  the  case,  it  is 
certain  that  our  final  MARC  master  would  not  have  been  as  relatively  clean  as 
it  was. 

These  remarks  so  far  have  been  a  sort  of  informal  parallel  or  supplement 
to  the  official  published  report  of  Harvard's  participation  in  the  MARC  Pro- 
ject, slanted  to  give  a  view  of  one  type  of  situation— hands-on  use  of  a  small, 
relatively  easy  to  understand  computer  whose  inherent  limitations  were  to  a 
large  degree  compensated  for  by  its  exceptional  accessibility  and  by  a  set  of 
aids  that  were  at  the  same  time  homemade  and  tailor-made. 

Now  let  us  pass  on  to  a  situation  that  in  many  ways  is  the  same  but  is 
also  very  different,  although  it  was  some  time  before  the  full  extent  of  the 
difference  became  apparent.  The  time  is  the  present  academic  year.  The  con- 
figuration is  the  same.  There  is  now  more  competition  for  the  machine,  both 
from  library  colleagues  and  from  refugees  from  another  1401  that  was  turned 
in.  Local  work  on  MARC  II  is  in  a  state  of  suspended  animation  because  a 
change  to  a  third  generation  machine  is  on  the  horizon.  These,  however,  are 
not  the  differences  of  which  I  speak.  Let  me  explain. 

The  Widener  punched  card  circulation  system  was  instituted  in  the 
summer  of  1963.  As  early  as  1964,  computer  processing  was  applied  to  the 
cards  for  two  periodic  tasks,  fine  billings  and  semiannual  overdue  reminder 
lists  for  faculty  members,  as  described  in  the  1965  document  on  the  system.^ 
In  1968  it  was  decided  to  replace  one  of  the  two  card  files— the  information 
file  in  call  number  order,  which  had  to  pass  through  the  collator  every 
day— with  a  magnetic  tape  and  a  daily  printout.  Since  I  had  designed  the 
punched  card  system  five  years  earlier,  it  seemed  only  logical  that  I  develop 
the  new  printout  system  for  circulation.  This  has  been  a  most  instructive 
experience  and  has  provided  the  second  of  my  three  differential  views. 
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Do  not  interpret  this  view  as  one  of  disillusionment  or  disappointment. 
The  printout  system  has  worked  very  well.  A  month's  parallel  operation  of 
the  old  system  and  the  new  was  planned;  well  before  that  time  was  over,  the 
circulation  division  unilaterally  dropped  maintenance  of  the  old  system.  No 
disaster  ensued;  this  is  not  the  account  of  a  fiasco.  Still,  as  I  shall  show,  there 
was  much  to  learn. 

First  draft  programming,  given  the  system  designer's  familiarity  with  the 
punched  card  format  of  his  own  invention,  went  quite  rapidly-a  matter  of  a 
few  weeks.  Debugging  and  polishing  time  was  not  excessive.  While  the  macros 
were  used  in  the  original  assembly  of  the  programs,  they  were  expanded  to 
one  card  per  line  in  a  new  source  deck,  and  some  of  the  luxury  options,  or 
safety  features  such  as  the  provision  for  warning  of  illegal  parameter  combina- 
tions (by  now  known  not  to  be  present  here)  were  weeded  out  in  a  hunt  for 
core  positions.  One  of  the  programs  ended  up  in  the  7990's  of  our  8K 
machine  even  after  these  excisions. 

Revisions  in  the  format  of  the  printout  based  on  experience  with  its 
actual  use  took  a  little  more  time,  as  did  slight  shortcuts  in  the  actual  running 
of  the  program.  For  instance,  at  first  the  opening  message  to  the  operator 
always  included  a  line,  "Use  48-character  print  chain."  The  revision  was  to 
print  this  only  when  the  1 20-character  chain  was  mounted,  as  determined  by 
a  test  tape  write.  Furthermore,  it  was  arranged  that  if  the  wrong  chain  were 
on,  the  computer  would  do  nothing  but  repeat  the  message  until  it  was 
changed.  In  this  case  a  machine  feature  already  spoken  of  as  potentially 
troublesome  was  turned  to  positive  advantage. 

This  last  example,  although  perhaps  trivial,  begins  to  get  close  to  the 
heart  of  the  matter.  There  was  far  more  than  anticipated  to  making  the  tran- 
sition from  the  old  hands-on  experimental  way  to  a  package  that  could  simply 
be  given  to  an  operator  to  run,  backed  up  by  the  documentation  required  for 
both  the  operator  and  the  circulation  division.  For  a  highly  relevant  example, 
what  happens  if  the  sort  program  prints  out  an  unreadable  tape  block  and  the 
system  designer  is  away? 

Please  note  that  the  departure  from  hands-on  operation  in  this  different 
situation  was  voluntary.  An  alternative  would  have  been  for  circulation  to 
have  its  own  data  controller  who  accompanied  the  job  and  held  its  hand  every 
night.  Systems  work  would  have  been  greatly  simplified  but  we  would  be  back 
to  the  question  of  a  backup  for  the  data  controller,  not  to  mention  the 
question  of  his  salary. 

Let  me  cite  a  small  detail  on  what  proved  to  be  the  nub  of  the  problem 
in  achieving  our  goal.  It  was  decided  to  substitute  a  computer  sort  for  a  card 
sort.  This  meant  that  there  would  be  one  program  to  edit  the  cards  and  put 
them  on  tape,  next  the  sort  program  supplied  by  the  manufacturer,  then  a 
tape  updating  program,  and  finally  a  printing  program.  It  was  convenient  to 
carry  the  last  two  programs  on  successive  master  tapes,  but  the  sort  program 
was  available  only  on  cards  with  our  particular  configuration,  and  it  worked 
out  best  to  use  cards  also  for  the  card  editing  and  taping  program. 

It  was  nothing  new  for  us  to  load  a  following  program  automatically  at 
the  end  of  a  preceding  one— in  fact,  the  standard  closing  macro  XYZ99  had  a 
parameter  which  provided  for  this.  There  was  just  one  thing— how  did  you 
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direct  the  operator  to  set  up  the  tapes  for  the  tape  update  when  you  did  not 
know  in  advance  which  unit  the  sort  output  was  going  to  come  out  on?  This 
varied  with  the  size  of  the  file  and  could  also  vary  with  its  degree  of  random- 
ness. One  early  thought  was  to  use  two  job  cards,  clearly  marked  1  and  2.  On 
the  second  card,  instead  of  calling  for  a  specific  reel  number  on  tape  unit  4, 
there  would  have  had  to  be  the  statement  (or  a  reference  to  a  statement  on 
the  other  side  of  the  card,  since  there  was  not  sufficient  room  on  the  front), 
"Use  sort  output  from  previous  program."  While  a  regular  operator  would  no 
doubt  get  used  to  this  quickly  enough,  the  chance  that  sometime  a  substitute 
would  find  it  too  confusing  and  there  would  be  a  disaster  seemed  too  great 
for  us  to  take. 

We  finally  elected  to  make  the  job  a  continuous  one  and  to  print  out 
instructions  (including  a  table  with  actual  reel  numbers)  which  varied  accord- 
ing to  the  unit  on  which  the  output  appeared.  This  routine  had  to  be  grafted 
onto  the  end  of  the  manufacturer's  sort  (while  the  output  tape  unit  number 
was  still  available),  which  led  into  some  study  of  that  8700  line  program. 
Adding  our  own  remounting  instructions  (once  they  were  written)  was  simple 
enough,  but  weeding  out  several  hundred  cards  for  unused  options  to  save  half 
a  dollar's  worth  of  card  reading  every'  night  was  more  of  a  task.  Then  there 
were  such  details  as  making  changes  so  that  the  entire  deck  including  param- 
eter cards  could  be  given  one  straight  through  numbering,  important  when 
there  was  card  reading  trouble. 

Our  own  addition  at  the  end  needed  to  read  a  card  which  was  changed 
daily,  giving  reel  numbers  of  tapes  to  be  used  and  of  the  previous  day's 
master.  The  print  program  also  required  one  card  to  be  read,  containing  the 
date.  When  we  began,  these  were  separate  cards;  after  all,  the  entire  tape  up- 
date program  (which  read  no  cards)  came  in  between.  One  evening  there  was  a 
substitute  operator,  who  was  given  a  brief  verbal  rundown  on  what  to  expect 
(documentation  was  not  yet  ready  at  that  time).  The  fact  that  one  card 
remained  in  the  reader  for  a  considerable  time  after  all  others  were  read  was 
mentioned  but  apparently  not  heard,  for  he  called  me  at  home  shortly  and 
said,  "It  wants  to  read  a  card."  He  had  run  out  the  reader  after  the  rest  of 
the  cards  were  read,  thinking  he  was  a  good  operator  to  do  so.  The  solution? 
Try  to  change  the  ingrained  habits  of  an  operator?  (The  regular  operator  when 
told  of  the  incident  confessed  that  he  had  done  the  same  thing  on  occasion, 
but  he  had  had  the  wit  to  retrieve  the  card  when  it  was  called  for.)  The 
solution  was  instead  to  combine  the  daily  data  required  by  the  second  and 
fourth  programs  onto  one  card,  read  by  the  second,  and  to  hold  the  twelve 
characters  of  information  required  for  the  fourth  over  in  the  highest  core 
positions  by  clearing  storage  for  the  last  two  programs  not  from  the  usual 
7999  down,  but  from  7987. 

Murphy's  Law  ("If  anything  can  go  wrong,  it  will")  tells  us  that  we 
should  provide  an  error  or  exception  routine  for  every  eventuality;  one  of  the 
programs  has  thirty  possible  messages  for  the  operator.  Our  earlier  programs 
of  course  had  messages,  but  they  were  messages  to  ourselves,  reminders  to  do 
something  we  understood  or  notices  that  something  anticipated  had  happened. 
What  might  be  called  life  or  death  messages  are  quite  another  matter.  At  this 
point,  the  problem  is  no  longer  computer  science  but  communications.  How 
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will  the  operator  understand  the  message?  In  what  ways  could  he  misunder- 
stand it? 

All  in  all,  it  is  necessary  to  build  into  the  system  proper,  if  possible,  and 
into  the  documentation  if  not,  a  substitute  for  the  knowing  presence  of  the 
systems  designer.  This  is  no  mean  task,  and  the  revision  of  the  circulation 
system  has  taken  months  rather  than  weeks.  It  has  given  us  a  fuller  apprecia- 
tion of  why  an  article  on  software  costs  by  Carl  H.  Reynolds  was  entitled 
"Notes  on  Estimating  and  Other  Science  Fiction."4 

What  is  the  combined  lesson  of  my  first  two  views?  If  one  is  developing 
something  new,  experimenting,  or  making  corrections  (whether  in  program  or 
data),  a  hands-on  environment  is  priceless.  When  a  job  becomes  routine  and 
must  be  done  whether  or  not  the  individual  is  present,  things  are  very  differ- 
ent and  the  ideal  is  to  wrap  up  a  package  that  can  be  given  to  someone  who 
has  never  seen  it  before  and  still  run  successfully. 

Let  us  now  consider  the  future.  The  future  of  computer  applications  in 
libraries  is  wide  open.  If  I  can  make  a  generalized  prediction,  perhaps  it  is  that 
economics  will  be  a  more  severe  limitation  than  technology. 

It  has  already  been  clearly  demonstrated  that  computer  processing  of 
bibliographical  records  (whether  for  whole  books  or  for  journal  articles)  is 
possible  not  only  technically  but  in  many  cases  economically.  Most  work  so 
far  has  used  batch  processing;  on-line  systems  are  very  attractive  for  many 
purposes  but  also  tend  to  be  very  expensive.  Even  in  batch  processing  of 
bibliographical  records,  which  is  the  most  widespread  form  of  activity,  there 
are  limitations  largely  based  on  cost.  Machine-readable  records  may  be  limited 
to  current  books  processed  since  the  new  system  was  introduced;  or  if  the 
entire  collection  is  covered,  the  records  are  probably  brief,  or  the  total  size  of 
the  collection  small.  No  large  library  has  yet  completed  the  task  of  converting 
its  entire  catalog,  not  to  mention  that  of  upgrading  the  level  of  its  subject 
cataloging  to  the  standards  desirable  for  new  machine  systems. 

Still  dealing  with  bibliographic  records,  but  at  a  level  beyond  batch 
processing,  we  may  consider  on-line  random  access,  whether  by  means  of  a 
dedicated  computer  or  by  time-sharing.  This  is  a  far  less  well-explored  field. 
The  possibilities  are  exciting  but  the  price  tags  are  high.  One  library  which 
actually  uses  this  type  of  facility,  a  disk  on  a  time-sharing  basis,  for  a  few 
weeks  a  year  while  editing  its  periodical  list,  reports  data  storage  costs  which 
work  out  to  be  on  the  order  of  a  dollar  a  year  per  title.  This  is  clearly  pro- 
hibitive for  general  use;  for  many  large  libraries  it  would  tend  to  double  total 
expenditures  (recent  observation  of  the  statistics  issued  by  the  Association  of 
Research  Libraries  indicates  that  annual  budgets  in  dollars  and  total  holdings 
in  volumes  are  often  in  the  same  range). 

Of  course  the  dollar  per  title  per  year  was  a  service  bureau  type  charge 
(though  non-commercial)  and  no  doubt  included  a  great  deal  of  overhead.  It 
may  have  allowed  for  much  more  activity  in  writing  data  on  and  off  the  disk 
than  actually  took  place.  A  far  more  favorable  cost  estimate  comes  from  the 
NELINET  (New  England  Library  Information  Network)  project  where  the 
storage  cost  per  title  per  year  on  a  large  owned  disk  tied  to  a  dedicated 
computer  might  be  as  low  as  five  cents.  At  this  cost  level  one  could  consider 
it,  however  painful  financing  even  this  may  be  where  books  are  counted  in  the 
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millions.  One  could  take  the  line  that  for  future  accessions  a  certain  average 
sum  should  be  set  aside  for  each  title  (hopefully  out  of  savings  realized 
through  having  machine-readable  catalog  data  available  from  a  central  source) 
as  what  might  be  called  endowment  for  that  book's  bibliographical  record 
being  kept  on-line.  At  five  cents  and  5  percent  interest,  this  works  out  to 
$1.00,  not  too  discouraging  an  amount.  These  figures  are  not  absolutely  solid, 
but  they  do  provide  food  for  thought. 

When  we  see  how  much  remains  to  be  accomplished  even  in  this 
relatively  developed  area  of  machine-readable  bibliographic  records,  is  it  worth- 
while even  speaking  of  the  tremendously  more  ambitious  possibility  of  putting 
the  entire  text  of  books  and  journals  in  our  libraries  into  machine-readable 
form?  The  answer  is  yes,  if  only  to  indicate  how  remote  it  is  as  a  practical 
economic  possibility,  and  to  consider  possible  alternatives. 

One  reason  that  the  question  is  inevitably  going  to  come  up  is  the 
problem  of  indefinite  expansion  of  library  buildings.  The  hopes  of  miniaturiza- 
tion first  raised  by  microphotography  and  now  by  digital  storage  are  worthy 
of  fairly  extended  discussion.  First,  let  us  consider  and  compare  the  quite 
different  approaches  of  ordinary  microfilm  (whether  roll  or  fiche)  and 
computerized  storage. 

Microfilm  has  these  advantages:  data  conversion  is  relatively  cheap, 
perhaps  on  the  order  of  two  cents  a  page  in  quantity  production.  Reading 
machines  are  low  in  cost  and  reader-printers  are  available.  Typographic  style, 
manuscript  annotations,  and  illustrations  are  reproduced.  Separate  color  films 
of  colored  illustrations  are  not  beyond  the  realm  of  serious  consideration  (the 
main  film  could  include  both  a  black  and  white  copy  of  such  an  illustration 
and  a  target  referring  to  placement  in  a  collected  color  roll  or  sheet).  Micro- 
film can  readily  be  copied.  Despite  recent  flurries,  it  is  relatively  permanent. 
Microfilm  technology  is  familiar  and  proved,  although  library  filming  typically 
uses  equipment  and  materials  developed  for  other  purposes  and  this  is  not 
entirely  satisfactory  for  use  in  the  library.  Harold  Morehouse  has  a  good 
phrase  in  an  issue  of  Library  Research  &  Technical  Services;  he  is  speaking  of 
telefacsimile  but  might  as  well  be  referring  to  microfilm  or  to  computers:  "It 
sometimes  seems  as  though  we  are  doing  something  like  using  an  electric  dish- 
washer to  wash  our  clothes."5  In  the  roll  microfilm  field,  the  absence  of 
standards  for  cartridges  seems  particularly  unfortunate. 

In  comparison  with  film,  digital  storage  has  one  potentially  tremendous 
advantage— it  is  machine-readable,  with  all  that  that  implies.  The  cost  of  copy- 
ing is  typically  even  lower  than  microfilm  for  equivalent  volumes  of  text,  but 
machine-readability  is  the  one  outstanding  advantage. 

Just  what  does  having  full  text  in  this  form  make  possible?  For  one 
thing,  there  is  an  advantage  in  transmissibility.  Optical  images  can  be  trans- 
mitted by  using  scanning  devices,  but  reducing  each  letter  to  the  typical  eight 
bits  rather  than  an  area  to  be  scanned  has  inherent  efficiencies.  Even  so,  large 
scale  over-the-wire  transmission  of  texts  of  books  or  even  articles  is  a  particu- 
larly clear  cut  example  of  a  situation  where  the  economic  factors  are  more 
limiting  than  the  technical.  Instant  display  via  a  character-generating  cathode 
ray  tube  is  another  somewhat  similar  area.  Again,  there  is  no  question  but 
that  it  can  be  done  once  the  information  is  encoded,  but  the  serious  question 
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is  how  economic  is  it  even  in  the  absence  of  the  long  line  tolls  which  are  such 
a  large  factor  in  data  transmission. 

The  situation  with  regard  to  automatic  indexing  and  abstracting,  and  in- 
formation retrieval  based  on  this  capability,  is  quite  different.  These  are 
primarily  software  rather  than  hardware  problems.  While  some  aspects- 
concordances,  KWIC  indexes,  vocabulary  studies— are  subject  to  what  might  be 
called  definitely  attainable  solutions,  others— automatic  indexing  and  abstract- 
ing, machine  translation— offer  what  amounts  to  an  infinitely  extensible 
challenge. 

Even  if  one  assumes  a  scarcity  of  indexers,  an  ample  supply  of  tape 
typists,  and  free  machine  time,  it  is  implausible  to  expect  that  articles  may  be 
indexed  equally  well  with  less  total  effort  (conceding  a  much  heavier  weight- 
ing to  the  indexer's  time)  by  re-keying  the  entire  text  and  then  submitting  it 
to  machine  analysis  than  by  more  conventional  ocular  and  cerebral  processes. 
Automatic  indexing  is  a  very  fascinating  intellectual  problem  that  draws  gifted 
scholars  because,  like  Everest,  it  is  there;  but  with  all  due  respect  to  the  in- 
telligent, ingenious,  and  hard-working  people  in  this  field,  it  will  become  a 
practical  economic  method  only  if  machine -readable  text  is  already  available. 

How  does  one  obtain  this?  Let  us  first  consider  the  optical  scanner  or 
page  reader.  Such  devices  are  already  in  fairly  wide  use,  most  successfully  with 
material  typed  in  a  font  specially  designed  for  the  purpose  but  still  quite 
legible  to  the  human  eye— much  more  so  than  the  magnetic  numerals  im- 
printed on  bank  checks.  Ordinary  typewriting  is  also  handled  fairly  success- 
fully if  paper  and  ribbon  quality  as  well  as  type  face  are  uniform.  Books  offer 
problems  of  quite  another  order,  including  varying  type  styles,  varying  width 
of  different  characters  within  the  same  font— an  m  is  wider  than  a  /—and  a 
much  larger  number  of  different  graphic  units  than  in  typewriting,  for 
example  the  ligature  for  fl.  This  is  not  to  mention  such  problems  as  page 
turners  if  original  non-expendable  books  are  to  be  used  as  source  copy. 

If  scanners  sophisticated  enough  to  read  books  rather  than  typed 
documents  are  developed,  it  is  reasonable  to  assume  that  they  will  be  more 
expensive  than  the  machines  of  more  limited  capability,  though  to  be  sure 
there  is  both  hope  and  some  reasonable  expectation  that  machine  costs 
generally  may  decline  if  considered  on  a  constant  dollar  basis.  However,  even 
assuming  both  that  the  problems  of  scanning  books  can  be  resolved  and  that  a 
secular  decline  in  machine  costs  cancels  the  premium  for  greater  sophistica- 
tion, the  fact  that  the  current  service  bureau  rate  for  scanning  the  easier  type- 
written material  is  on  the  order  of  one  cent  per  line  helps  put  this  avenue  in 
proper  perspective. 

There  is  one  other  possibly  royal  road  to  machine-readable  full  text, 
although  it  is  possible  that  if  I  had  cost  data  on  it  I  would  have  another 
reason  for  a  lapse  into  pessimism.  It  is  of  no  help  at  all  with  books  of  the 
past,  unless  they  are  reprinted.  However,  I  believe  it  may  have  great  worth  in 
the  future.  Many  type  composition  processes  right  now  and  all  photo- 
composition devices  that  I  know  of  use  a  machine-readable  tape  as  a  regular 
step  in  the  process.  If  these  compositors'  tapes  could  be  translated  into  regular 
computer  tapes,  we  might  at  last  be  on  the  track  of  machine-readable  full 
text  at  a  reasonable  price.  However,  of  course,  there  are  problems.  The  tape 
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(commonly  punched  paper  at  the  present  time)  is  machine-readable,  but 
usually  only  by  a  very  special  machine.  It  may  be  wider  than  standard,  with 
more  channels;  special  hardware  would  be  required  for  translation  and  hopes 
for  economy  would  fade.  If  the  tape  is  physically  compatible  with  computer 
tape,  there  will  probably  still  be  problems.  Simple  code  differences— the  use  of 
different  punch  or  blip  combinations  for  the  same  letter— are  readily  suscep- 
tible to  a  software  solution.  The  presence  of  special  typographic  codes  may  be 
more  troublesome,  but  can  still  be  solved  by  software.  A  larger  problem,  and 
really  the  crux,  is  the  matter  of  errors.  Many  otherwise  advanced  systems  still 
use  manual  methods  of  correction,  so  that  the  final  corrections  never  get  on 
the  tape.  Compositors'  tapes  will  become  a  really  useful  source  of  full  text  data 
only  when  computer-aided  editing  systems  are  used  and  final  tapes  are  clean. 
Fortunately,  such  editing  systems  also  offer  great  possibilities  for  improved 
efficiency  to  publishers,  who  cannot  be  expected  to  go  out  of  their  way 
merely  to  produce  a  by-product  useful  to  someone  else. 

The  preceding  discussion  has  assumed  that  full  text  in  machine-readable 
form  would  be  desirable  if  we  could  get  it.  Certainly  there  are  many  purposes 
for  which  this  is  so,  even  if  we  defer  the  concept  of  remote  display.  Full  text 
analysis  has  already  revolutionized  the  making  of  concordances.  One  wonders 
how  many  uses  of  words  earlier  than  the  first  recorded  in  such  works  as  the 
New  English  Dictionary  would  be  turned  up  by  a  computer  search  of  a  whole 
library.  An  algorithm  that  would  detect  proper  names,  or  even  potential 
proper  names,  by  their  typographical  characteristics,  could  make  possible 
prodigies  of  indexing.  It  will  be  a  long  time  before  such  capabilities  can  be 
applied  to  large  general  collections,  but  it  is  worth  beginning  to  think  about 
them. 

I  have  not  meant  to  create  the  impression  that  bibliographic  records 
only  and  full  text  are  the  alternatives  and  that  there  is  nothing  in  between. 
Among  intermediate  steps  are  machine-readable  (but  humanly  composed) 
abstracts  and  citation  indexing,  the  latter  a  particularly  active  and  promising 
field. 

Where  does  all  this  leave  us?  Through  a  glass  darkly  I  see  something  like 
this:  while  I  agree  that  we  should  be  accumulating  data  for  the  future  insofar 
as  it  is  available  from  compositors'  tapes,  and  I  hope  such  availability  will  be 
encouraged  by  a  standards  effort  and  by  development  of  central  repositories,  I 
think  that  full  text  processing  will  long  be  limited  to  special  situations  and 
will  not  be  in  the  realm  of  financial  possibility  for  universal  application  in  the 
foreseeable  future  (whatever  the  foreseeable  future  may  be). 

I  do  think  conversion  of  bibliographical  records  for  books,  including  full 
retrospective  conversion  (but  not  immediate  upgrading),  is  within  the  realm  of 
the  feasible,  given  a  major  effort  by  the  national  library  and  full  cooperation 
from  other  major  libraries.  Our  old  friend  the  analytic,  seen  less  and  less  often 
among  new  additions  to  card  catalogs,  may  make  a  comeback  in  machine 
systems.  Machine-readable  indexing  of  current  journal  articles  is  already  a 
reality  in  a  number  of  fields  and  it  seems  reasonable  to  hope  that  it  may  be 
extended  to  all,  but  retrospective  coverage  of  all  articles  is  a  much  more 
formidable  problem. 
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I  do  not  think  whirling  magnetic  disks  or  comparable  larger  devices, 
inherently  high  in  cost  and  subject  to  hazards  of -data  loss  which  require 
elaborate  and  expensive  backup,  are  the  last  word  in  storage  for  library 
records.  Rather,  I  see  a  more  stable,  permanent,  read-only  tape  memory  (read 
only  after  original  entry,  of  course),  hopefully  of  vast  size  and  low  unit  cost, 
which  will  contain  the  body  of  the  description  of  each  title,  with  numbers 
referring  to  the  various  headings— author,  added,  subject— which  refer  to  it. 
The  description  could  have  a  permanent  number  and  additions  of  new  batches 
could  be  made  in  accession  order  at  the  end  of  the  file.  A  revised  entry  would 
be  a  new  entry,  leaving  the  old  one  unused  until  such  time  as  a  general 
rewriting  of  the  entire  file  was  required,  when  it  could  be  dropped. 

While  the  various  names,  subject  headings,  etc.,  would  also  appear  in 
their  own  read-only  authority  file,  they  would  also  have  to  exist  in  a  more 
active  medium  which  would  refer  by  number  to  all  the  full  records  to  which 
the  heading  applied,  and  to  which  new  accession  numbers  would  constantly 
be  added.  Title  and  classification  number  files  with  provision  for  interfiling 
would  also  be  needed.  Ordinary  access  to  the  main  permanent  descriptive  file 
would  be  indirect,  through  the  active  heading,  title,  or  class  files.  There  would 
be  provision,  however,  for  periodic  seriatim  search  of  the  entire  file  for 
combinations  of  characteristics  not  findable  through  the  usual  keys. 

Until  a  full  on-line  catalog  of  this  sort  can  be  developed  and  afforded, 
it  might  be  worth  considering  having  the  basic  file  on  tape,  used  via  a  book 
catalog,  with  supplementary  titles  (including  information  on  those  on  order 
and  in  process)  in  an  on-line  system. 

These  remarks  on  the  possible  future  of  the  computerized  catalog  are 
speculative;  even  more  speculative  will  be  anything  I  can  say  about  automated 
text  access.  There  would  seem  to  be  considerable  promise  in  mixed  systems, 
storing  text  (and  illustrations)  in  micro-image  form  and  retrieving,  trans- 
mitting, and  displaying  it  under  computer  control.  Project  INTREX  at  the 
Massachusetts  Institute  of  Technology  is  doing  some  interesting  work  in  this 
field,  but  the  fact  that  a  device  mentioned  favorably  in  their  reports  has  a 
capacity  of  45,000  pages  is  some  suggestion  of  what  a  long  road  there  is  to 
travel  before  large  general  libraries  are  covered  by  systems  of  this  type.  In  the 
meantime,  perhaps  it  is  worth  thinking  about  wider  use  of  ordinary  hand- 
retrievable  microfilm  as  an  interim  backup  facility.  For  really  is  there  not 
something  incongruous  about  investing  very  large  sums  in  advanced  com- 
puterized catalogs  when  they  refer  solely  to  original  copies  of  books  that  are 
subject  to  all  the  hazards  of  being  out,  not  on  the  shelf,  etc.,  that  are  so 
familiar  in  present-day  university  library  collections?  This  would  also  be  a  step 
toward  the  desirable  goal  of  taking  some  of  the  wear  from  our  aging  stocks  of 
original  books. 

This  paper  has  raised  many  questions  to  which  I  do  not  know  the 
answers.  However,  my  general  conclusions  are  that  libraries  and  computers 
have  a  great  future  together,  but  that  economic  factors  and  the  sheer  size  of 
large  libraries  will  slow  full  application  of  many  exciting  possibilities  that  will 
first  be  explored  and  developed  in  more  specialized  situations.  Finally,  micro- 
film, both  conventional  and  automated,  must  not  be  overlooked  as  a  com- 
plement to  computerized  systems. 
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BELL  LABORATORIES  ON-LINE  CIRCULATION 
CONTROL  SYSTEM:  ONE  YEAR'S  EXPERIENCE 


An  on-line,  real-time  computer  circulation  system  has  been  in  use  by  the 
Technical  Information  Libraries  of  the  Bell  Telephone  Laboratories  since 
March  1968.  In  its  initial  configuration  the  BELLREL  (Bell  Laboratories 
Real-Time  Loan)  system  links  two  terminals  in  each  of  the  company's  three 
largest  libraries— at  Holmdel,  Murray  Hill  and  Whippany,  New  Jersey— to  an 
IBM  360-40  computer  at  Murray  Hill.  The  system  is  designed  to  process  loans, 
returns,  reservations  and  a  range  of  information  queries  with  real-time 
immediacy  and  responsiveness;  in  addition,  batch  operations  provide  multiple 
reports  and  other  products  necessary  to  the  effective  control  and  management 
of  library  resources.  Basic  to  the  objectives  and  performance  of  the  whole 
system  is  a  computer-stored  record  of  the  major  publication  resources  of  the 
participating  libraries. 

During  the  first  year  of  operation,  with  not  all  the  total  collection 
complete  on  disk,  BELLREL  handled  over  105,000  loans  and  250,000  trans- 
actions (i.e.,  loans,  returns,  reservations,  and  queries)  in  real-time.  This  paper 
reviews  the  objectives  and  principal  features  of  the  system  and  describes  its 
performance,  uses,  problems  and  impact  during  the  first  twelve  months  of 
daily  service. 

SYSTEM  ENVIRONMENT  AND  OBJECTIVES 

Any  effective  system  must  be  a  good  servant  in  its  environment,  and 
even  a  brief  consideration  of  a  system  requires  some  exposure  to  the  context 
in  which  it  functions.  The  environment  for  which  BELLREL  was  designed  is 
characterized  by  a  large  population  of  library  users;  rapidly  mounting  informa- 
tion demands;  dispersed  collections  and  operations;  a  heavy  volume  of  mail, 
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telephone,  and  recorded  message  requests;  and  a  major  commitment  to 
computer-aided  systems.  More  specifically,  the  Technical  Information  Libraries 
network  includes  eighteen  library  units  serving  some  16,000  Bell  Laboratories 
people  in  nine  states  and  at  Kwajalein  Island  in  the  Pacific.  Nine  of  these 
libraries  are  jointly  operated  with  the  Western  Electric  Company  (the  manu- 
facturing and  supply  unit  of  the  Bell  System)  and  also  serve  Western  engineers 
at  these  sites.  Total  circulation  in  the  library  system  is  now  close  to  half 
a  million  items  per  year,  including  one-way  computer  documents,  technical 
reports  and  other  publications.  The  three  libraries  first  linked  into  the 
BELLREL  system  handle  about  75  percent  of  all  this  traffic,  generate  over 
40,000  overdue  notices  per  year,  hold  92  percent  of  all  the  book  and  journal 
titles  in  the  library  system  and  serve  on-site  (but  not  exclusively)  some  12,000 
Bell  Laboratories  people. 

The  many  reasons  which  compelled  investigation  of  a  computer-aided 
replacement  for  the  manual  charge  system  used  by  Bell  Laboratories  Libraries 
for  some  forty  years  have  been  given  in  an  earlier  paper1  and  will  not  be 
detailed  here.  Perhaps  it  will  be  sufficient  to  observe  that  the  imperatives  were 
significant.  The  objectives  established  for  the  new  system  merit  restatement, 
however,  since  they  bear  directly  on  the  selected  design  and  its  subsequent 
performance. 

Library  management  concluded  in  1965  that  any  new  system  had  to: 

1.  Meet    the    long-range    needs    of   the   major    libraries    in    Bell 
Laboratories  and  be  extensible  to  other  units  in  the  library  network  as 
traffic,  costs  and  experience  warranted. 

2.  Provide  not  only  a  more  effective  means  for  handling  circula- 
tion operations  within  the  walls  of  any  one  library  but  also  an  instru- 
ment for  knocking  walls  down,  for  bringing  the  combined  resources  of 
the  dispersed  libraries  to  bear  on  any  information  need. 

3.  Give  up-to-the  minute  accounting  for  all  items  off  the  shelves 
and  locate  copies  still  available  for  use: 

4.  Handle  all  types  of  materials,  bound  or  unbound,  and  all  types 
of  requests  whether  in  person,  by  mail,  direct  telephone  or  Telereference 
(i.e.,  recorded  message)  service. 

5.  Hold    reservations    against    system    resources    and    follow    up 
on  reserve  queues  automatically,  directing  the  first  copy  available  any- 
where to  the  first  person  waiting,  wherever  located. 

6.  Identify  all  items  currently  or  formerly  charged  to  a  borrower. 

7.  Reduce  circulation  staff  labor  and  refocus  it,  where  possible, 
on  more  personal  service  to  library  users. 

8.  Monitor    circulation   traffic   in    depth   and   provide   feedback, 
sufficiently  rich,  meaningful  and  timely,  to  enable  management  to  react 
appropriately. 

9.  Integrate  satisfactorily  with  other  computer-aided  systems  in 
use  or  planned  in  the  libraries. 

10.  Above  all,  improve  the  total  response  of  the  Library  to  the  user. 
Translation  of  these  objectives  into  practice  dictated  not  only  a  real-time 
system  for  recording  items  on  loan  or  demand  but  one  built  around  the  use  of 
on-line  accessible  records  of  pooled  bibliographic  resources. 
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It  is  interesting  to  note  that  in  a  recent  paper  Audrey  Grosch  of  the  Univer- 
sity of  Minnesota  lists  the  benefits  which  would  accrue  from  an  on-line 
circulation  system  having  "at  its  heart  a  file  structured  to  handle  both  biblio- 
graphic and  operational  data."^  All  seven  benefits  which  she  mentions  are 
included  in  the  objectives  given  above.  All  have  been  realized  in  the 
BELLREL  system. 

Before  discussing  the  actual  performanace  of  the  system,  however,  a 
brief  review  of  its  principal  characteristics  would  be  appropriate.  Since 
BELLREL  has  been  described  in  some  detail  in  an  earlier  paper1,  what  follows 
is  a  summary  of  only  the  salient  features. 

PRINCIPAL  FEATURES  OF  THE  BELLREL  SYSTEM 

Network  Configuration 

Library  terminals:  total  of  six  IBM  1050  terminals,  each  incorporating  a 
1052  keyboard-printer  and  a  1056  card  reader  for  maximum  flexibility  in 
handling  all  types  of  transactions 

Telecommunications  links:  Western  Electric  103 A  Data-Sets  using  voice 
grade  telephone  lines 

Computer:  IBM  360-40  with  262K  byte  core  memory,  in  the  comp- 
troller's division  at  Murray  Hill 

Network  distances:   one-quarter  mile,  twelve  miles  and  thirty  miles. 

Computer  Usage  and  Programs 

Computer  sharing:  BELLREL  on-line  operations  and  heavy  batch 
processing  (for  comptroller's  division  purposes)  run  concurrently 

Operating  mode:  MFT  (Multiprogramming  with  a  Fixed  Number  of 
Tasks),  i.e.,  the  dynamic  area  of  core,  as  distinct  from  the  360  Operating 
System  area,  is  partitioned  into  four  segments,  each  of  which  is  independent 
with  respect  to  job  scheduling,  initiation  and  termination.  The  partitions  are 
assigned  processing  priority.  A  job  in  a  given  partition  gains  control  when 
another  job  in  another  partition  must  wait  for  the  completion  of  some  event, 
such  as  reading  records  from  tape.  A  job  in  a  lower  priority  partition,  (e.g., 
Partition  3-batch  processing)  is  suspended  when  a  higher  priority  job  is  ready 
to  resume.  The  BELLREL  on-line  system  is  assigned  the  highest  priority,  using 
Partition  0  (the  teleprocessing  logic  of  the  IBM  Queued  Teleprocessing  Access 
Method)  and  Partition  1  (message  editing  and  BELLREL  applications 
packages).  Viewed  from  the  library  end,  BELLREL  appears  to  own  the 
computer. 

BELLREL  programs:  about  thirty-two  real-time  and  twenty-three  batch 
programs.  Input-output  and  message  processing  programs  are  written  in  Basic 
Assembly  Language  and  the  balance  in  COBOL  level  F. 

On-Line  Man  File 

Purpose:  through  man  number,  to  supply  all  necessary  information 
about  an  actual  or  potential  borrower  and  his  current  loans,  if  any 

Coverage:  19,000  people  and  thirty-six  special  non-personal  borrower  codes 
for  sister  libraries,  internal  operations  (e.g.,  binding,  new  book  shelf,  missing),  etc. 
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Update  frequency:  daily 

Storage  medium:  IBM  2316  disk  pack 

Access  method:  index  sequential  on  five-digit  man  (payroll  account) 
number 

Record  elements:  161  characters  including  man  number,  name,  address, 
department,  occupational  class,  loan  data,  keys  to  overflow  trailers,  etc. 

On-Line  Publication  File 

Purpose:  through  title  number,  to  supply  all  necessary  bibiliographic  and 
transaction  data  for  loans,  reserves  and  resource  queries 

Coverage:  initially,  four  classes  of  publications* 
Books  (Class  1)-35,000  titles,  66,000  volumes 
Journals  (Class  2)-2,700  titles 

Suppliers'  Catalogs  (Class  3)-5,000    \    when  conversion 
College  Catalogs  (Class  4)- 1,000       f    is  complete 

Update  frequency:  weekly 

Storage  medium:  IBM  2316  disk  pack 

Access  method:  for  books,  direct  on  six-digit  title  number,  the  first  digit 
of  which  is  a  1 ;  for  other  publications,  index  sequential 

Book  record  elements:  188  characters  including  book  number,  forty- 
three  characters  of  author-title,  call  number,  copies  by  location,  maintenance 
change  data,  three  loans,  two  reserves,  trailer  keys,  etc.  Lqan  fields  give 
borrower  number,  copy,  date  due,  loan  status,  etc. 

Journal  record  elements:  155  characters  including  journal  number, 
forty-three  characters  of  title,  maintenance  change  data,  two  loans,  one  reserve 
and  trailer  keys.  Unlike  books,  records  of  all  copies  and  volumes  of  each  title 
are  not  permanently  stored.  Bound  volumes  and  unbound  issues  are  recorded 
on  this  record  only  while  on  loan  or  reserve.  Punch  cards  and  labels  have  been 
computer-produced  for  over  20,000  volumes. 

Other  publication  records:  comparable  to  journal  records  except  that 
each  separate  supplier  or  college  catalog  is  specifically  identified  and  recorded. 

History  File 

Purpose:  to  provide  statistics,  user  analyses  and  other  management  in- 
formation 

Coverage:  all  completed  loan  transactions 

Update  frequency:  daily  transfer  from  the  publication  disk  file  of 
completed  loan  data 

Storage  medium:  magnetic  tape 

Record  elements:  item  number,  author-title  data,  call  number,  number 
of  loans,  date  returned,  copy  number,  man  number  (or  non-personal  code 
such  as  "Lost"),  department,  occupational  class,  etc. 


*A   fifth   class,  originally   established  for  cataloged  continuations  and  multiple-volume 
titles  cataloged  as  sets,  has  been  restructured  and  combined  with  books. 
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On-Line  Transactions 

Input  message  elements:  transaction  code  plus  item  number  and/or  man 
number,  depending  upon  the  transaction 

Input  method:  All  message  elements  are  normally  keyed  except  when  a 
publication  punch  card  is  available,  i.e.,  for  loans  and  returns. 

Transaction  codes:  Ten  codes  exist  for  loans,  returns,  reservations  and 
renewals.  The  use  of  three  of  these  codes  is  shown  in  Figure  1.  Twelve  codes 
are  available  for  queries  about  publications  or  people.  Three  queries  are  shown 
in  Figure  2.  Additional  codes  provide  for  inter-terminal  communication  and 
obtaining  statistical  logs  of  traffic  (Figure  3)  at  each  terminal. 

Error  detection:  Each  input  item  number  and  man  number  is  translated, 
after  disk  lock-up,  in  the  returned  response.  Numberous  diagnostics  are  also 
returned  for  invalid  codes,  items,  input  sequences,  etc.  Samples  are  given  in 
Figure  4. 


Loan  of  3  books  to  1  person 
1ml*  JltSC 
3l00980mh01 
al23523mh01 
al05613mh02        * 
KEN    GINZBERG,    E./    LOST    D 
KEN    CHUNG,    K.L.    MARKOV    C 
KEN    RUNO,    H. /    DIFFERFNTI 

Adding  a  reserve 


1339335,100980* 

STA, GINZBERG,  E./  LOST  0, 301 . 15/PU9L  ,RFS  »  01, CA  HO  00-00  MH  01-00  UH  01-01 

Reserve  no.^^      /  Holdings  /      / 

Copies  available  Copies  on  hand 

1362736,100980* 

WAR,niNZBFRG,    E./    LOST   D, 301. 15/Gl*9L    ,RES    I    02, CA   HO  00-00   MH    01-00   WH    01-01 


lai»75i(6, 123523* 

CLY, CHUNG,  K.L.  MARKOV  C,519/C55-2    ,RES  *  01, CA  HO  01-01  MH  01-00  ,JH  01-00 


]C  Return  with  automatic  reserve  pick-up 

a!00980rnh01 

a!23523mh01 

3l05613mh02    * 

GINZBERG,  E./  LOST  D  LOAN  TO    39335  STANTON,R  0  MH1F237    1WK 

CHUNG,  K.L.  MARKOV  C  LOAN  TO    U75U6  CLYNE,J  M  MH3D280    2WK 

RUND,  H./  niFFERFNTI  RETURNED 

No  one  waiting  ' 


Figure  1  -  Sample  Loan,  Reserve  and  Return  Transactions 


BELL  LABORATORIES  ON-LINE  CIRCULATION  CONTROL  SYSTEM       19 


What  it  on  loan  to  ...  ? 


Iq16636l*# 

SHR 

120922, DF.LMONTF,  vl .  PLAS.TIC, 

120923, nF.LMONTF,  J.  PLASTIC, 

130359, HARRIS,  C.M./  SHOCK  , 

739323, J    APPL   flFCH  ,16-7/1*0-50 

130352, HARRIS,  C.M./  SHOCK  , 

111*86!*,  TIMOSHFNKO,  S./  FLEM, 
130515, MORROW,  C.T.  SHOCK  A, 

GG3fii»,  SHROFF,  J  R/MM1F219  /111  'jl30,006  ROOKS  001  OTHFR 


Who  has ...  ? 


lqw!0597G# 

DIXON,  J.J./  INTROD  ,  519.7/DG2-2 

HO    03-02    Mil    03-03   WH    02-00       *    RES    00 

JH01    STAFFORD, A   JH7A261  5759    G908U 

H003    0    NEILL,L      H03FI209  1*261+    H9999 

WII02    SEIDELMAN,    JH3E207  3215    G9078 
THATS    ALL 


Who  it  waiting  for  ...  ? 


Iqxl35l*98# 

DINN,    M.F.    ESTIMATIO,  ,T1/D58 

HO    01-00   MH    00-00   WH    00-00 

RES'    01,r,OTZ,B  ,  58627, H03R510  , 25UO,  02UEFKS  OLD 

RES#    02,SFIDMAfJ,L    ,  Ufi356/JH?!J2l»2  ,  6218,  ni'JFFKS  OLD 

RES*    03,HF.FFES,H      ,  50870, WH1M217  ,  2335,  Ol'./FFKS  OLD 
THATS    ALL 


Figure  2  -  Sample  of  Three  Queries 
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BELLREL  AT  WORK 

Some  appreciation  of  the  uses  to  which  BELLREL  is  put  may  be  gained 
from  the  repertoire  of  on-line  commands  and  the  variety  of  batch  products 
(see  Figure  5).  In  our  earlier  paper  we  also  described  standard  procedures  for 
making  loans,  handling  returns  and  processing  reservations.  The  degree  in 
which  the  new  system  has  altered  old  procedures  and  become  an  integral 
element  in  library  services  may  be  better  conveyed,  however,  by  reviewing 
some  typical  operations. 

Locating  a  Book 

A  scientist  cannot  find  a  given  book  on  the  shelves.  He  inquires  at  the 
circulation  desk.  Pre-BELLREL,  the  clerk  checked  the  loan  cards,  consulted 
the  union  card  catalog  to  determine  what  copies  were  held  and  where,  called 
one  or  more  libraries  as  appropriate,  relayed  the  scientist's  name  and  address 
if  a  copy  were  found  or,  if  all  were  in  use,  decided  which  library  should  add 
his  name  and  address  to  its  reserve  list,  etc. 
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Iql77989# 

INVALID  MAN  MO    779S9 


Iqcl3821i** 

INVALID    ACCESS    MO    15C21U 


123i»5G# 

INVALID  TRANSACTION-COMMA 


, 123U5Gmhol# 

INVALID  TRANSACT  I  Of'  BAD  LOAN  PEP.'lOD 


INVALID  TRANSACTION  3 AD  LOCATION  CODE 


ITEM  .?  127257  PURG 


Figure  4  —  Sample  Error  Messages 
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1.  OVERDUE  NOTICES  DAILY 

2.  LOAN  LISTS  DAILY 

3.  CARDS  AND  LABELS  WEEKLY 

4.  BOOK  &  JOURNAL  CATALOGS  QUARTERLY 

5.  CATALOG  SUPPLEMENTS  WEEKLY 

6.  CIRCULATION  STATISTICS  MONTHLY 

7.  TITLES  IN  DEMAND  WEEKLY 

8.  RESERVE  OUEUE  AGING  WEEKLY 

9.  GET  OFF  THE  SHELF  WEEKLY 

10.  MISSING  ITEMS  BIWEEKLY 

11.  LOANS  BY  USING  DEPT.  MONTHLY 

12.  LOANS  BY  SUBJECT  MONTHLY 

13.  SUBJECT  USAGE  BY  DEPT.  MONTHLY 

14.  ZERO  ACTIVITY  LIST  SEMIANNUAL 


Figure  5  -  Some  Batch  Products  of  BELLREL 
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In  the  on-line  system,  the  clerk  finds  the  book's  control  number  in  one 
of  the  BELLREL  printed  catalogs  before  him  and  then  keys  in  the  reservation 
code  with  man  number  and  book  number.  The  computer  responds  in  three  to 
five  seconds  giving  book  data  and  call  number,  the  holdings  and,  as  of  that 
moment  in  time,  the  number  of  copies  available  in  each  of  the  three  libraries 
(Figure  1).  It  also  identifies  where  the  requester  stands  in  the  waiting  queue, 
if  there  is  one.  If  all  copies  are  in  use,  then  the  requester  knows  where  he 
stands  in  the  queue  and  what  the  system  resources  are  to  meet  his  need.  And 
if  he  must  see  a  copy  promptly,  the  on-line  LQW  command  (Figure  2)  will 
identify  all  borrowers,  their  locations  and  telephone  numbers,  thus  permitting 
him  to  get  in  touch  with  the  nearest  one.  If,  however,  a  copy  is  reported  to 
be  available  in  another  library,  then  that  library  is  asked,  by  telephone  or 
terminal  message,  to  send  call  number  such-and-such  "out."  The  holding 
library  gets  the  book  from  its  shelves  and  cancels  it.  This  charges  the  requester 
with  the  book,  assigns  him  the  correct  loan  period,  and  identifies  him.  The 
dispatch  follows. 

As  a  result  the  on-line  system  eliminates  two  or  more  card  file  look-ups, 
provides  up-to-date  facts  on  holding  (What  large  library  has  not  a  filing  back- 
log for  its  card  catalog?),  determines  exactly  where  copies  are  available  at  the 
moment  of  need,  gets  the  nearest  one  on  its  way  to  him  or  insures  (as  the 
manual  system  simply  could  not)  that  his  need  will  be  met  from  automatic 
reserve  queue  follow-up  on  any  copy  returned  anywhere  in  the  system. 

Handling  Library  Bulletin  Requests 

One  of  the  library's  eight  regular  current  awareness  bulletins  is  the 
Library  Bulletin  announcing,  among  other  publications,  several  hundred  books 
each  month.  Requests  for  these  books  are  submitted  on  tear  sheets,  citing 
item  numbers.  Over  600  requests  are  received  in  the  first  few  days  after 
Bulletin  issue.  In  pre-BELLREL  practice,  a  clerk  in  each  library  had  to 
identify  the  book  associated  with  the  item  number  and  write  each  requester's 
name  and  address  on  the  charge  card  (if  held  locally)  or  if  not,  on  an  inter- 
unit  request  card.  In  this  inter-unit  interchange  request  priorities  got  badly 
disturbed,  charge  records  were  duplicated  and  system  resources  were  used  in- 
efficiently. Further,  while  each  library  attempted  to  scan  the  card  files  and 
flag  high-demand  titles  for  additional  purchases,  follow-up  tended  to  be  slow, 
incomplete,  uncoordinated  and  needlessly  duplicative. 

In  the  BELLREL  system,  Library  Bulletin  request  forms  supply  both 
the  BELLREL  item  numbers  and  the  requester's  number.  The  processing  clerk 
posts  batches  of  requests,  using  the  on-line  reserve  transaction,  and  ignoring, 
pro  tern,  the  computer  responses  concerning  copy  availability.  He  then  takes 
the  print  out  (one  of  several  reasons  for  selecting  typewriter  response  rather 
than  cathode  ray  tube  display)  and  proceeds  to  act  on  the  messages.  Books 
available  locally  are  collected,  cancelled  in  lots  of  five  using  the  BELLREL 
cancel  or  return  command  and  thereby  are  automatically  charged  and  directed 
to  the  queued  requesters.  For  books  available  elsewhere  in  the  system,  he  can 
send  the  flagged  print  out,  or  a  copy,  to  one  or  more  of  the  libraries;  alter- 
natively, if  the  weekly  Get  Off  the  Shelf  List  (Figure  6)  is  due,  he  takes  no 
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action  on  these  items  because  this  list,  which  goes  to  each  library,  will 
identify  all  cases  where  copies  are  available  and  someone  is  waiting.  It  will  be 
apparent  that  this  list  is  also  a  persistent  machine  follow-up  on  any  human 
failure  to  retrieve  a  needed  book  from  the  shelves. 

The  Titles  in  Demand  List  (Figure  7)  is  also  a  very  powerful  tool  in 
getting  new  books  promptly  to  the  waiting  audience.  This  is  a  weekly  report 
which  documents  all  titles  for  which  there  are  more  than  five  people  waiting. 
Both  the  frequency  and  the  threshold  can,  of  course,  be  altered  as  required. 
The  list,  in  classification  order,  identifies  each  title,  each  library's  holdings, 
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and  the  number  of  people  waiting  by  location  (including  locations  other  than 
the  BELLREL  libraries).  It  also  flags  items  listed  for  the  first  time  and,  most 
importantly,  shows  the  ratio  of  requests  to  copies  available.  When  the  three 
library  supervisors  receive  this  list,  they  set  up  a  telephone  conference  session 
and  decide  what  additional  copies  shall  be  ordered  immediately,  by  which 
libraries,  to  meet  the  demonstrated  demand. 

The  results  of  all  these  changes  hardly  need  emphasis:  faster  service; 
coordinated,  prompt  and  economic  buying  to  meet  real  need;  more  complete 
exploitation  of  the  collection;  reduced  clerical  effort  and  record-keeping,  and 
so  on. 

Controlling  the  Collection 

In  the  manual  system,  missing  items  were  recorded  by  signaling  charge 
cards,  if  available,  or  writing  the  facts  on  a  card  used  to  designate  missing 
items.  Periodically  these  cards  were  assembled  in  shelflist  order,  checked  against 
the  shelves,  rechecked,  etc.— a  cumbersome  and  imperfect  procedure.  Overdue 
notice  procedures  were  particularly  tedious  involving  card  signaling,  pulling, 
Xeroxing  on  forms,  refiling,  etc.  Clearing  departing  employees  involved  no 
systematic  record-checking;  it  was  impossible  without  a  borrower's  file. 

The  computer  system  has  had  a  major  impact  on  all  of  these  account- 
ability operations.  As  soon  as  an  item  is  reported  as  missing,  it  is  recorded 
on-line  using  one  of  two  codes:  ME9,  if  the  borrower  cannot  locate  it,  and 
MS9  for  all  other  missing  conditions.  Every  two  weeks  the  system  produces  a 
Missing  Items  List  (Figure  8)  in  shelflist  order,  giving  all  the  appropriate  details. 
Items  new  to  the  list  are  flagged.  Each  library  uses  a  copy  of  the  list  to  search 
the  shelves,  keeping  an  eye  open  for  any  copies  from  another  library  which 
may  have  wandered.  After  several  iterations  of  this  process,  items  are  located, 
or  new  orders  placed,  or  charged  to  lost.  The  "lost"  codes  are  equivalent  to 
the  "missing"  codes,  resulting  in  a  history  tape  record  permitting  further 
analysis,  as  desired. 

Generating  overdue  notices  (Figure  9)  is  completely  automatic  each  day, 
on  a  three-cycle  basis.  Determining  a  borrower's  charges  is  immediate,  using 
an  on-line  query  code.  If  an  employee  should  leave  without  returning  all 
library  items,  a  report  is  produced  automatically  by  the  man  file  maintenance 
program. 

Managing  Information  Resources 

Each  library  supervisor  in  Bell  Laboratories  is  responsible  for  meeting 
the  differing  literature  needs  of  the  researchers  at  his  location.  Each  must  also 
buy,  shift  and  purge  publications  in  the  context  of  total  system  resources. 
Without  adequate  feedback  on  who  is  using  what,  where,  and  how  often, 
decisions  may  too  often  be  guesses.  A  range  of  systematic  and  comprehensive 
reports  is  now  available  to  aid  decision-making.  The  Titles  in  Demand  List  is 
one  of  a  family  of  these  tools.  The  weekly  Reserve  Queue  Aging  report 
identifies  unfilled  requests  in  terms  of  a  sequence  of  waiting  times.  The  Loans 
by  Subject  report  records  the  sum  of  all  uses  of  each  four-digit  Dewey  subject 
class.  Since  this  identifies  the  borrower's  base  location,  rather  than  a  specific 
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library's  traffic  (as  the  complementary  Circulation  Statistics  report  does),  it 
enables  the  librarians  to  determine  when  and  where  subject  collections  should 
be  shifted  to  meet  on-site  browsing  needs.  The  Subject  Usage  by  Department 
report  identifies  the  use  made  by  each  center  and  laboratory  of  each  subject 
class.  With  these  latter  data,  each  library  supervisor  knows  whom  to  consult  to 
get  advice  on  purchases  and  purges.  For  the  latter  purpose,  he  has  an 
additional  tool,  the  Zero  Activity  List,  a  semi-annual  report  on  all  titles  which 
have  had  no  recorded  use  during  that  time,  plus  the  total  of  previous  uses,  if 
any. 
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SOME  ON-LINE  USAGE  DATA 

During  the  first  year  of  operations,  with  data  files  still  incomplete, 
BELLREL  handled  an  average  of  1,000  on-line  transactions  per  day— more 
than  two  per  minute.  Loads  have  been  as  high  as  1 ,900  transactions  per  day. 
Many  of  the  transactions  have  been  of  the  multiple-entry  type,  handling  one 
to  five  items  in  one  input. 

A  sampling  of  5,500  transactions  gives  the  following  distribution  by 
major  class  of  operation:  loans— 25  percent,  returns— 25  percent,  queries— 18 
percent,  reserves— 18  percent,  and  renewals— 14  percent. 

Of  the  approximately  180  queries  per  day,  75  percent  are  concerned 
with  publications  and  25  percent  with  people.  The  number  of  queries  is 
expected  to  increase  significantly  as  the  full  capabilities  of  the  system  become 
more  completely  appreciated  by  the  clerical  staff. 

Transactions  which  are  input  in  incorrect  format  or  with  incomplete 
data  are  intercepted  by  the  message  edit  program  and  returned  to  the  sender 
(Figure  4).  These  errors  amount  to  about  1  percent  of  all  on-line  inputs. 

PROBLEMS 

Since  the  system  has  become  an  integral  part  of  library  operations  and 
impinges  on  numerous  activities,  any  down-time  is  unwelcome.  It  is,  of  course, 
inevitable.  On  one  occasion,  the  system  was  inoperative  all  day.  Two  hours 
down-time  out  of  42.5  hours  per  week  has  not  been  uncommon  during  the 
first  year  of  system  de-bugging,  modification,  training  and  conversion  to  a  new 
360  Operating  System.  Many  of  the  causes  have  been  trivial  (e.g.,  a  broken 
type  head  or  drive  belt  on  the  master  console)  or  localized  (e.g.,  card  reader 
errors).  Surprisingly  few  difficulties  have  been  the  product  of  BELLREL 
programming,  although  in  one  notable  case,  date  due  miscalculations  near  the 
end  of  the  1968  leap  year  had  interesting  effects.  On  the  whole,  down-time 
has  been  more  than  expected  but  rarely  troublesome.  Circulation  operations 
continue,  using  down-time  logs  which  are  immediately  entered  into  the 
re -activated  system. 

Few  problems  have  been  encountered  with  the  operators.  Staff 
members,  particularly  those  with  no  previous  library  experience,  have  adapted 
rapidly.  Early  cases  of  inattention  to  BELLREL  responses  have  largely  dis- 
appeared. Some  tendency  to  consult  the  card  catalog  or  the  daily  loan  list 
(essentially  a  system  back-up)  rather  than  to  invoke  the  full  query  powers  of 
the  system  still  exists.  The  effective  error  rate  continues  to  be  very  low, 
largely  due  to  the  programmed  responses  to  each  input.  Free  key-boarding  of 
bibliographic  data  for  unbound  journal  issues  is  the  greatest  single  error-prone 
operation,  calling  for  care  in  both  charges  and  returns.  Other  publications  and 
transactions  present  no  problem. 

COSTS 

The  verdict  on  total  costs  of  the  on-line  system  versus  the  displaced 
manual  system  is  not  yet  in.  The  operation  costs  of  BELLREL  are  clearly 
higher  than  the  manual  system  but  comparative  cost/benefit  ratios  are  another 
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matter  entirely.  The  new  system  has  resulted  in  some  substantial  labor  and 
materials  savings  but  its  total  influence  on  library  operations  and  services  is  so 
extensive  and,  in  some  respects,  subtle,  that  a  complete  assessment  has  not  yet 
been  possible.  To  cite  an  example,  one  of  three  book  catalogs  generated  by 
BELLREL  is  a  Dewey-ordered  record  of  all  the  book  holdings  of  the  three 
major  libraries.  The  availability  of  this  quarterly  catalog,  up-dated  by  weekly 
cumulations,  has  allowed  these  three  libraries  to  discontinue  shelflist  mainte- 
nance in  the  card  catalog,  with  known,  appreciable  savings.  Copies  of  these 
book  catalogs  are  also  provided  to  eleven  more  distant  libraries  which  hereto- 
fore had  no  record  of  the  resources  of  the  libraries  holding  92  percent  of  all 
the  titles.  The  reaction  to  these  precursors  to  a  system-wide  printed  book 
catalog  has  been  enthusiastic;  the  value  for  cost  calculations  is  indeterminable, 
as  are  speed  of  service,  record  accuracy,  enriched  feedback  and  other  in- 
tangible benefits. 

Further  observations  about  costs  are  given  in  our  earlier  paper.1  Cost 
studies  are  continuing.  BELLREL,  however,  is  only  one  component  in  a 
developing,  integrated  computer-aided  system  involving  acquisitions,  catalog- 
ing, announcement  and  access.  The  interactions  between  these  functions  will 
call  for  new  costing  perspectives. 

BELLREL  is  an  attempt  to  control,  or  solve,  a  complex  of  troublesome 
problems  in  a  particular  library  environment,  in  one  segment  of  time,  with 
off-the-shelf  equipment,  and  at  acceptable  cost.  Within  that  environment  its 
impact  has  been  sharply  manifest.  It  has  been  doing  what  it  was  designed  to 
do— and  more;  unanticipated  by-product  benefits  continue  to  emerge. 

The  servo-mechanistic  force  of  the  system  is  naturally  most  obvious  to 
the  library  people  who  manipulate  it.  A  little  input  generates  a  lot  of 
response.  Things  happen  more  quickly— from  knowing  when  to  buy  added 
copies,  to  following  up  on  reserve  queries,  to  obtaining  information  about 
holdings.  Tedium  is  down;  productivity  is  up;  service  is  improved;  and,  as  the 
wealth  of  user  and  traffic  data  accumulates,  decision-making  in  the  interests  of 
making  a  tighter  correlation  between  information  needs  and  resources  will,  we 
believe,  be  greatly  enhanced. 

What  BELLREL  has  meant  to  the  individual  library  user  is  less  well 
known.  Many  scientists  and  engineers  have  expressed  strong  technical  interest. 
Many  understand  how  the  system  works  for  them.  Others,  it  seems,  would 
accept  conveyor  belts  or  carrier  pigeons,  as  long  as  information  needs  were 
met.  But  while  some  library  users  do  not  yet  perhaps  fully  realize  what  the 
system  is  doing,  or  can  do,  for  them,  there  is  clearly  a  wide  appreciation  that, 
in  on-line  computer  technology,  library  service  has  acquired  a  powerful  help- 
mate whose  enlarging  future  is  assured. 
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LIBRARY  NETWORKS:  CATALOGING 
AND  BIBLIOGRAPHIC  ASPECTS 

In  The  Future  of  the  Research  Library,  Verner  Clapp  comments  on  the 
"two  principles  which  have  controlled  the  growth  of  libraries— the  principle  of 
local  self-sufficiency  and  the  principle  of  sharing  the  resources."1 

It  is  becoming  increasingly  clear,  however,  that  adherence  to  the  princi- 
ple of  self-sufficiency  is  no  longer  economically  feasible  or  rationally  desirable 
for  libraries.  Pragmatic  problems  of  spiralling  costs  of  labor  and  material, 
physical  problems  of  space,  and  intellectual  concern  over  bibliographic  control 
of  the  burgeoning  information  explosion  all  play  their  part  in  contributing  to 
the  demise  of  such  an  insular  concept. 

Sharing— in  the  guise  of  cooperation,  centralization,  regionalization— is 
the  "in"  concept  of  the  day.  This  concept  is  not  new;  shared  resources 
through  interlibrary  loan,  centralized  cataloging  through  LC,  and  regional 
systems  through  state  and  other  agencies  have  existed  at  varying  levels  for 
many  years.  Serendipitous  development  of  such  programs,  however,  no  longer 
seems  sufficient  and  the  rapid  growth  of  new  technologies  has  given  impetus 
to  the  development  of  the  more  sophisticated  concept  of  networks.  The 
computer,  graphic  display  techniques,  TWX  hook-ups,  and  facsimile  trans- 
mission all  portend  far  more  encompassing  cooperative  ventures  than  hereto- 
fore envisioned. 

To  define  precisely  and  with  certainty  what  it  is  that  distinguishes  a  net- 
work from  the  cooperative  efforts  we  have  known  by  other  names  in  the  past 
has  proved  to  be  a  difficult  task.  Becker  and  Olsen  who  define  a  network  in 
the  broadest  of  terms  in  their  survey,  "Information  Networks,"  refines  the 
concept  somewhat  as  it  applies  to  information  networks,  but  still  admits  that 
"since  the  network  concept  is  very  young,  the  terminology  associated  with  it 
is  still  evolving,  and  some  confusion  regarding  definitions  must  be  expected."2 
When  personal  colleagues,  both  librarians  and  computer  people,  were  asked  to 

31 


32  ANN  T.  CURRAN 

define  what  makes  a  library  network  a  network  they  produced  many  in- 
teresting viewpoints  but  no  clarification,  leading  to  my  concluding,  with  Hiatt, 
that  "we  librarians  will  find  ways  to  share  the  processing  of  materials  when- 
ever we  feel  it  necessary  and  will  find  labels  and  definitions  later."3 

According  to  Becker  and  Olsen  the  main  characteristics  of  an  ideal 
automated  information  network  (none  of  which,  they  claim,  is  operationally 
extant  "at  present")  are: 

1)  Formal  Organization.  Many  units  sharing  a  common  informa- 
tion purpose  recognize  the  value  of  group  affiliation  and  enter  into  a 
compact. 

2)  Communications.    The    network    includes    circuits    that    can 
rapidly  interconnect  dispersed  points. 

3)  Bi-directional  Operation.    Information    may    move    in    either 
direction,  and  provision  is  made  for  each  network  participant  to  send  as 
well  as  to  receive. 

4)  A   Directory   and  Switching  Capability.   A  directory  look-up 
system  enables  a  participant  to  identify  the  unit  most  able  to  satisfy  a 
particular  request.  A  switching  center  then  routes  messages  to  this  unit 
over  the  optimum  communications  path.4 

If  one  concept  can  be  said  to  be  common  to  the  various  views  ex- 
pressed, it  would  be  that  networks  involve  the  use  of  sophisticated  (electronic) 
equipment  and  sophisticated  communications  techniques.  Accepting  then  this 
rather  loose  definition,  this  paper  will  be  dealing  with  those  cooperative 
efforts  among  libraries  which  involve  sophisticated  equipment.  The  discussion 
will  be  restricted  to  cooperative  processing  operations— in  particular  catalog- 
ing—excluding the  consideration  of  those  processing  operations  involved  in 
acquisitions,  as  well  as  consideration  of  networks  devoted  to  the  sharing  of 
resources.  The  problems  that  have  always  faced  cooperative  cataloging  process- 
ing operations  will  be  discussed,  as  well  as  the  impact  of  computer  technology 
as  it  offers  solutions  to  some  of  these  problems,  but  poses  complications  of  its 
own.  The  experiences  of  the  New  England  Library  Information  Network 
(NELINET)  as  they  relate  to  the  topic  of  cooperative  cataloging  processing 
will  be  reported.  Since  the  author's  background  and  experience  have  not  been 
in  public  or  school  libraries,  this  paper  will  be  slightly  slanted  towards  college 
and  university  libraries. 

COOPERATIVE  PROCESSING 

Among  the  advantages  usually  claimed  for  centralized  processing  are  the 
bringing  together  of  able  staff  and  expensive  tools  and  equipment,  and  making 
these  tools  and  skills  jointly  available  to  many  libraries  that  could  not  have 
afforded  them  on  their  own.  Cooperative  participation  in  computer  processing 
facilities  may,  likewise,  be  prompted  by  considerations  of  money  and  man- 
power. Such  cooperative  efforts  can  be  expected  especially  in  those  areas  of 
library  automation  that  are  most  difficult  and  most  expensive  for  libraries  to 
develop  and  operate  on  their  own. 

The  processing  involved  in  a  cataloging  operation  is  one  such  difficult 
and  expensive  area.  First,  the  developmental  costs  for  a  computerized  system 
are  high.  It  is  much  more  difficult  to  specify  the  requirements  for  a  catalog 
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card  production  system  and  translate  these  requirements  into  terms  program- 
mers can  understsnd  than  it  is  to  specify  a  circulation  system.  And  once 
specified,  there  is  still  a  long  hard  road  ahead  before  programs  are  running 
smoothly.  As  is  the  case  with  most  text  processing,  considerable  amounts  of 
programming  talent  and  time  are  required  to  produce  efficient  systems. 

Second,  equipment  requirements  must  be  considered.  The  computing 
center  in  any  one  library's  parent  institution  may  not  have  the  special  output 
devices  to  produce  the  quality  of  printing  libraries  consider  necessary  for  dis- 
playing cataloging  data  satisfactorily.  If  the  more  sophisticated  concept  of 
on-line  access  to  bibliographic  data  is  considered,  the  additional  cost  of  storing 
such  large  files  can  also  be  expected  to  encourage,  if  not  to  require,  the 
sharing  of  the  high  cost  of  equipment  for  such  a  data  base. 

Third,  if  libraries  are  to  make  use  of  the  machine-readable  bibliographic 
data  being  issued  by  the  Library  of  Congress,  it  will  again  mean,  for  most 
libraries,  that  they  do  it  cooperatively.  How  many  libraries  can  afford  to 
search  MARC  tapes  independently? 

In  addition  to  fostering  cooperation,  computers  have  had  an  impact  on 
libraries  in  another  area— that  of  encouraging  standardization.  Standard  rules 
and  practices  have  been  the  goals  of  librarians  for  years  and  the  effect  that 
the  increasing  number  of  processing  centers  has  had  in  encouraging  standard- 
ization should  not  be  overlooked.  The  "Guidelines  for  Centralized  Technical 
Services"  state  that  the  "adoption  of  uniform  policies  and  regulations  is  the 
key  to  efficient  and  economical  operation."5  It  has,  however,  taken  the 
computer  to  add  a  sense  of  urgency  to  these  efforts. 

The  uninitiated  might  question  the  need  for  such  pronouncements  on 
standardization;  those  who  have  worked  in  more  than  one  library  will  not. 
The  variations  in  practice  that  may  be  found  in  libraries'  cataloging  processing 
operations  are  seemingly  endless.  Functionally  speaking  these  variations  can 
be  divided  into  three  main  categories:  I)  those  which  evolve  in  the  intellectual 
efforts  of  cataloging  and  classification,  II)  those  which  evolve  in  the  genera- 
tion of  catalog  cards,  spine  labels,  and  book  cards,  and  III)  those  which  evolve 
in  physical  preparation  of  the  book. 

I.  Variations  in  cataloging  and  classification  practice  cover  the  following 
major  areas  of  concern: 

1)  the  choice  of  main  entry; 

2)  the  making  of  added  entries; 

3)  the  establishing  of  names  and  titles; 

4)  the  amount  of  descriptive  detail  given  in  the  title  paragraph, 
collation,  or  notes; 

5)  the  subject  heading  list  used; 

6)  the  classification  scheme  used.  If  Dewey,  which  edition?  The 
treatment  of  fiction  and  biography;  and 

7)  the   book   numbering   scheme    used.    Library   of  Congress  or 
another  Guttering  scheme?  If  Cutter  tables,  which  ones?  How  are  dif- 
ferent titles  and  editions  indicated? 

Variations  in  areas  1  through  4  are  to  be  expected  if  libraries  follow 
different  cataloging  codes.  But  even  when  libraries  follow  the  same  cataloging 
rules,  differing  interpretations  of  these  rules  can  lead  to  variations. 
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II.  If  we  were  to  examine  the  practices  of  libraries  relating  to  the  genera- 
tion of  catalog  cards,  spine  labels,  and  book  cards  we  would  again  find  many 
variations,  including: 

1)  the  format  of  the  catalog  card; 

2)  the  distinction  between  subject  headings  and  added  entries; 

3)  the  indication  of  copies  in  multiple  locations  within  a  library 
system.  Are  separate  sets  of  cards  made  for  each  location  or  is  the  card 
set  in  the  main  catalog  annotated  (e.g.,  "copy  also  in  Reference")?; 

4)  the  number  of  each  type  of  card  (e.g.,  main  entries,  shelflist 
card,  etc.)  required  for  each  title  processed; 

5)  the  symbols  used  to  indicate  special  locations  such  as  Refer- 
ence; 

6)  the  printing  of  branch  location  symbols  on  spine  labels,  on 
book  cards,  and  on  the  catalog  cards  for  the  branch  catalog; 

7)  the  formatting  of  Library  of  Congress  call  numbers  on  catalog 
cards  and  labels; 

8)  the  determination  of  an  oversized  book,  the  symbols  used  to 
represent  oversize,  and  the  positioning  of  this  symbol; 

9)  the  data  put  on  the  shelflist  card— e.g.,  date  and  price  as  well  as 
copy  and  volume  data; 

10)  the  printing  of  copy  and  volume  numbers  on  spine  labels; 

11)  the  use  of  book  cards; 

12)  the   size   of  the   type  used  on  spine  labels  (bulletin,  pica, 
other); 

13)  the  copy  numbering  system  used.  Is  it  one  over-all  system  for 
all   locations   within   a  library  system  or  do  different  locations  have 
separate  numbering  schemes?  and 

14)  the  type  of  card  stock,  spine  labels,  and  book  cards  used. 

III.  If  a  processing  center  were  involved  in  book  preparation  for  a  number 
of  libraries  there  would  also  be  differences  in: 

1)  how   ownership   is   indicated   (perforations   or  stamping)  and 
where  it  is  placed; 

2)  where  book  plates,  book  pockets,  and  date  slips  are  placed  in 
the  book; 

3)  where  a  spine  label  is  positioned  on  the  spine  of  a  book; 

4)  if  and  where  the  call  number  is  pencilled  in  the  book; 

5)  if  shellac  or  lacquer  is  used  on  the  book  and  if  so,  on  the 
entire  book  or  the  spine  only; 

6)  if  covers  are  used,  and  if  so  what  size  and  type; 

7)  if  and  where  price  and  source  are  written  in  the  book.  If  price 
is  written,  what  price— list,  net,  other; 

8)  if  books  are  lettered  rather  than  labelled,  are  they  lettered  in 
white,  gold  or  black;  and 

9)  if  and  where  the  blurb  is  posted  in  the  book. 

Since  the  actual  physical  preparation  of  the  book  continues  to  be  un- 
affected by  automation,  a  major  concern  of  this  paper,  further  consideration 
of  the  problem  of  variations  in  this  area  will  not  be  included  here. 


LIBRARY  NETWORKS  35 

If  a  processing  center  were  to  include  the  entire  range  of  catalog  pro- 
cessing operations  for  a  number  of  libraries,  it  would  probably  encounter  all 
the  differences  in  practice  noted  above  plus  a  few  more.  Examination  of  the 
practices  of  an  experimental  processing  center  will  illustrate  the  relative  sig- 
nificance of  these  variable  factors,  as  well  as  their  implications,  in  terms  of 
cooperative  processing  procedure. 

NELINET 

The  New  England  Library  Information  Network  (NELINET)  project  is 
an  attempt  to  establish  a  computerized  processing  center  for  New  England 
libraries.  It  is  sponsored  by  the  New  England  Board  of  Higher  Education  and 
funded  by  a  series  of  grants  from  the  Council  on  Library  Resources.  The  state 
university  libraries  of  Connecticut,  Massachusetts,  New  Hampshire,  Rhode 
Island,  and  Vermont  are  the  present  participants,  but  NELINET  is  envisioned 
as  a  regional  system,  eventually  capable  of  serving  any  New  England  library. 

Early  in  NELINET's  development,  the  decision  was  made  to  begin  with 
the  area  of  technical  processing,  giving  initial  attention  to  cataloging. 
Additional  services  contemplated  include  acquisitions,  union  lists,  book  form 
catalogs,  circulation  and  interlibrary  loan  control,  library  management  in- 
formation, and  remote  data  base  interrogation. 

A  MARC  I-based  pilot  operation  to  produce  catalog  cards  and  Selin 
labels  began  in  December  1967  and  continued  through  July  1968.  A  new 
MARC  II-based  system  has  been  designed  and  is  presently  being  programmed. 

As  might  be  expected,  numerous  variations  in  practice  were  found 
among  the  five  libraries.  Most  of  these  were  in  the  second  category  noted 
earlier,  the  generation  of  cards  and  labels,  but  some  were  due  to  differences  in 
cataloging  and  classification  practices.  Some  of  the  variations  were  accommo- 
dated through  programming,  while  others  were  not.  The  card  production 
program  included  a  "profile"  for  each  library  containing  information  about 
the  processing  practices  of  the  library.  The  cards  were  then  generated  accord- 
ing to  these  specifications. 

Perhaps  the  biggest  hurdle  for  any  cooperative  effort  to  overcome  is 
defining  what  should  be  standardized  and  what  variations  will  be  allowed.  In 
making  these  decisions  for  the  NELINET  system,  two  factors  were  taken  into 
account— the  burden  it  would  impose  on  the  library  to  change  its  existing 
practice  and  the  amount  of  programming  that  would  be  required  to  provide 
for  different  practices.  On  the  basis  of  these  two  considerations  the  following 
decisions  were  made: 
I.  In  the  area  of  cataloging  and  classification 

A.  Standardize 

Since   Library  of  Congress  cataloging  copy  is  being  used  at  present, 
standardization  has  been  achieved  on  most  of  the  points  in  this  area. 

B.  Allow  Variations 

1 .  Making  added  entries 

Each  library's  profile  specifies  whether  subject  added  entries  are  to 
be  made  for  main  entries  that  are  subjects.  Libraries  with  divided  catalogs 
where  names  as  subjects  are  filed  in  the  subject  catalog  may  then  receive 
the  subject  cards  desired. 
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2.  Printing  Library  of  Congress  conventional  titles 

The  NELINET  system  is  programmed  to  accommodate  the  options 
regarding  conventional  titles  allowed  in  the  MARC  II  format.  A  library 
may  choose  to  have  all  Library  of  Congress  conventional  titles  printed  on 
their  cards,  to  have  them  all  omitted,  or  to  print  only  those  that  appear  on 
Library  of  Congress  printed  cards. 

3.  Classification  scheme  used 

Three  of  the  five  libraries  use  the  Library  of  Congress  classification; 
the  other  two  use  Dewey.  If  the  library  does  not  wish  to  use  the  call 
number  established  at  the  Library  of  Congress,  it  may  enter  its  own  call 
number.  This  may  be  a  Dewey-based  number  or  another  Library  of 
Congress  number. 

II.  In  the  area  of  generating  catalog  cards,  spine  labels,  and  book  cards 
A.  Standardize 

1 .  The  format  of  the  catalog  card 

There  is  one  standard  format  for  print  out.  The  class  number  and 
the  main  entry  begin  on  line  four.  The  call  number  is  limited  to  six  char- 
acters per  line  appearing  in  print  positions  2  through  7.  The  main  entry 
begins  in  print  position  10.  Indentions,  whether  hanging  indentions  for 
title  main  entries  or  regular  indentions  beginning  new  paragraphs,  are  at 
print  position  12.  There  are  no  spaces  between  lines.  Subject  overprint 
headings  are  in  upper  case. 

2.  The  indication  of  copies  in  multiple  locations 

Three  of  the  five  libraries  used  separate  sets  of  cards  in  the  main 
catalog  for  each  book  location.  The  other  two  libraries  used  only  one  set, 
indicating  on  this  set  the  other  copy  locations. 

The  NELINET  system  decided  to  make  separate  sets  of  cards  for 
each  copy  location. 

3.  The  printing  of  branch  location  symbols 

The  branch  symbol  appears  on  all  labels  and  on  all  catalog  cards. 

4.  The  formatting  of  the  Library  of  Congress  call  number 

Each  of  the  three  libraries  using  Library  of  Congress  classification 
broke  up  their  call  numbers  differently  in  formatting  the  call  number  in 
the  margin  of  the  catalog  card  and  on  the  spine  labels.  Since  breaking  up 
the  call  number  string  into  line  segments  involves  a  considerable  amount  of 
programming,  it  was  decided  to  standardize  and  only  one  way  was  pro- 
grammed. The  format  chosen  is:  class  letters  on  one  line,  class  numbers 
and  numeric  decimal  subdivisions  on  the  next  line  (if  this  exceeds  six 
characters,  the  decimal  and  the  numbers  following  are  put  on  the  next 
line),  chronological  (year)  class  subdivisions  on  a  new  line,  each  Cutter 
number  on  a  line,  eliminating  the  period  before  the  first  Cutter.  The  data 
following  the  Cutter  is  segmented  in  what  the  computer  can  determine  to 
be  reasonable  units. 

5.  The  printing  of  copy  numbers  and  volume  numbers  on  the  spine 
labels 

If  more  than  one  copy  is  owned,  the  copy  number  is  printed. 
Volume  number  designations  are  also  printed. 
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6.   The  type  size  used  on  spine  labels 

Bulletin,  executive,  and  pica  types  were  all  being  used  by  the 
libraries  in  their  existing  systems.  The  NELINET  labels  are  typed  on  a 
Dura  with  pica  type. 

7.  The  type  of  card  stock,  and  spine  labels 

No  variations  were  provided  for  because  of  the  trouble  involved  in 
changing  forms.  At  present,  Remington  Rand  continuous  card  stock  is 
being  used.  Since  one  of  the  libraries  has  complained  about  the  quality, 
the  system  may  change  to  another  card  stock.  Selin  labels  are  used.  One  of 
the  libraries  does  not  want  Selin  labels  so  labels  are  not  made  for  them. 
The  profile  for  each  library  indicates  whether  labels  are  wanted. 
B.  Allow  Variations 

1 .  The  number  of  each  type  of  card 

The  system  accommodates  the  differences  in  card  requirements 
among  the  libraries  and  within  each  library  system.  The  profile  for  each 
library  contains  the  number  of  main  entries,  added  entries,  subject  entries, 
and  shelflist  cards  desired  for  titles  held  in  the  main  stacks  of  the  main 
library,  for  each  special  shelf  location  within  the  main  library,  and  for  each 
branch.  The  appropriate  number  of  cards  are  then  generated  automatically, 
triggered  by  the  location  symbol  of  the  title  being  processed.  For  in- 
stance, if  the  title  being  processed  is  for  the  main  stacks  of  the  main 
library  of  the  University  of  New  Hampshire,  the  profile  calls  for  four  main 
entry  cards  (one  for  the  catalog  and  three  to  be  sent  to  three  neighboring 
New  Hampshire  state  colleges),  one  copy  of  each  added  entry,  and  a  shelf- 
list  card,  all  of  which  are  generated  by  the  computer  program. 

If  a  library  wishes  more  main  entries  than  their  usual  requirement 
for  a  particular  title,  they  may  obtain  them  by  indicating  on  their  process- 
ing-request worksheet  the  number  of  extra  copies  desired. 

2.  Symbols  used  to  indicate  special  locations  such  as  Reference 

No  attempt  was  made  to  have  the  libraries  standardize  such 
symbols.  The  profile  for  each  library  contains  the  location  symbols  used 
with  the  desired  number  of  catalog  cards  indicated  for  each  location. 

3.  The  determination  of  an  oversized  book 

Rather  than  have  the  libraries  change  to  a  standard  oversize  deter- 
mination, the  system  allows  for  variations  in  oversize  determination  among 
the  libraries  (but  not  within  a  library).  It  also  allows  different  oversize 
symbols  to  be  used.  It  does  not  allow  for  differences  in  positioning  of  the 
symbol.  The  symbol  is  placed  on  the  line  above  the  class  number. 

4.  Data  put  on  the  shelflist  card 

Since  some  of  the  libraries  use  an  over-all  copy  numbering  scheme 
including  all  locations,  while  others  have  separate  copy  numbering  for  each 
location  (and  one  includes  branches  with  the  main  scheme  but  uses 
separate  numbering  for  each  special  shelf  location  within  the  main  library, 
e.g.,  Reference),  printing  copy-volume  data  on  shelflist  cards  is  rather 
complex.  The  system  does  not  as  yet  print  copy-volume  data  on  shelflist 
cards.  The  data  is  identified  and  stored,  but  further  systems  work  is  re- 
quired before  it  can  be  printed  properly  in  all  cases. 
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We  have  seen  in  the  NELINET  experience  that  computerized  systems 
can  accommodate  many  different  processing  practices  with  little  expense  of 
human  effort.  Since  it  is  possible  to  program  a  system  which  can  accom- 
modate almost  any  variation,  the  question  of  what  to  standardize  and  what 
variations  to  allow  becomes  a  question  of  economics,  not  of  technical  feasi- 
bility. Allowing  variations  does  involve  additional  expense— the  cost  of  the 
additional  programming  required,  plus  the  cost  of  the  additional  machine-running 
time  to  operate  the  system.  The  additional  programming  time  is  a  one-time 
expense;  the  additional  running  time  is  not. 

The  libraries  participating  in  the  development  of  NELINET  are  univer- 
sity libraries.  With  the  exception  of  using  Library  of  Congress  catalog  copy 
and  cards,  university  libraries  have  not  entered  into  cooperative  or  centralized 
arrangements  to  any  extent.  That  five  libraries  have  been  willing  to  accept 
products  in  some  respect  different  from  their  own  is  indicative  of  the  coopera- 
tive spirit  and  realistic  attitudes  of  the  librarians  involved. 

MACHINE-READABLE  FORMATS  FOR 
BIBLIOGRAPHIC  RECORDS 

Before  assuming  that  computers  have  solved  the  problem  of  standards  in 
the  bibliographic  world,  let  us  consider  the  variations  that  computers  them- 
selves introduce.  Machine-readable  bibliographic  records  may  vary  in  a  number 
of  ways  including: 

1)  the  content  of  the  record— the  data  that  is  included  to  describe 
the  item  processed; 

2)  the  recording  of  the  data.   Is  it  recorded  in  natural  language,  in 
coded  form,  or  both?   If  in  natural  language,  is  the  data  normalized  to  an 
authorized  form?; 

3)  the  determination  of  items  that  are  to  be  separately  identified 
in  the  record; 

4)  the  manner  of  identification  of  these  items— as  tagged  fields, 
delimited  subfields  within  a  tagged  field,  or  assigned  positions  within  a 
field; 

5)  the  structure  of  the  machine  record.  Are  the  identifying  tags 
interspersed  with  the  data?;  and 

6)  the  character  set  used  to  represent  the  data. 

With  the  acceptance  of  the  MARC  II  format,  the  library  community  has 
achieved  standardization  in  all  the  areas  mentioned  above.  This  is  no  minor 
achievement,  and  the  importance  of  acceptance  of  the  MARC  II  standard  to  the 
development  of  library  automation  in  this  country  and  elsewhere  cannot  be  over- 
estimated. 

It  should  be  noted,  however,  that  the  MARC  standard  was  able  to  build 
upon  the  standardization  already  present  in  the  bibliographic  records  produced 
for  library  catalogs.  Since  libraries  generally  follow  the  ALA  cataloging  code, 
the  content  of  the  record  and  the  form  of  names  are  already  more  or  less 
standardized.  Such,  however,  is  not  the  case  with  all  producers  of  biblio- 
graphic records— the  abstracting  and  indexing  services,  for  example. 

The  proposed  "U.S.A.  Standard  Format  for  the  Communication  of 
Bibliographic  Information  in  Digital  Form"  covers  only  the  structure  of  the 
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machine  record  (number  6,  above).  Whether  abstracting  and  indexing  services 
will  ever  achieve  the  same  level  of  standardization  as  libraries  is  open  to 
question.  Also  open  to  question  is  the  desirability  and  feasibility  of  combining 
both  traditional  cataloging  records,  and  the  records  of  abstracting  and  indexing 
services  in  a  single  machine  file.  Can  the  differences  in  processing  practices  be 
reconciled  in  a  single  machine  file?  Perhaps  a  more  basic  question  to  ask  is,  will 
librarians  continue  to  consider  the  journal  article  and  other  non-book  forms  to  be 
outside  their  province? 

As  in  most  discussions  of  cooperative  processing  for  libraries,  this  paper 
has  dealt  mainly  with  the  topic  of  standardization.  It  might  well  have  been 
subtitled  "Standards  vs.  Local  Options."  What  to  standardize,  what  to 
mechanize,  and  what  to  centralize  are  decisions  that  every  processing  network 
will  have  to  make  in  terms  of  its  own  needs  and  capabilities.  This  paper  has 
indicated  that  such  decisions  can  be  made  and  can  be  implemented. 

Whether  libraries  should  unite  because  of  location  of  members,  size  of 
collection,  type  of  library  (college,  public,  school),  or  configurations  of 
subject  holdings  remains  to  be  seen.  NELINET  incorporates  two  of  these 
criteria:  the  members  (at  present)  are  all  university  libraries  (type  of  library) 
and  are  all  in  the  New  England  area  (location  of  members).  But  whether  this 
represents  the  best  combination,  whether  others  are  better,  or  whether  any 
combination  would  be  equally  valid  has  yet  to  be  determined. 

Can  the  dichotomous  needs  of  shared-resources  networks  and 
shared-cataloging  networks  be  reconciled,  and,  if  so,  to  what  extent?  On  what 
level?  The  strength  and  purpose  of  shared-resources  networks  lie  in  the  diver- 
sity of  the  holdings  of  its  members.  A  major  advantage,  on  the  other  hand,  of 
a  shared-cataloging  network  lies  in  the  economics  attainable  through  elimina- 
tion of  duplicative  efforts  and  this,  in  turn,  predicates  similar  rather  than  dis- 
parate collections.  Yet,  the  composite  data  base  which  can  be  derived  from 
shared  cataloging  systems  constitutes  a  powerful  finding  tool  for  use  in 
shared-resources  networks. 

Also  facing  such  networks  is  the  problem  of  evaluating  their  cost  and 
efficacy.  What  will  their  services  cost?  What  do  the  manual,  independent 
systems  which  they  expect  to  replace  cost  now?  How  timely  will  network 
services  be?  How  much  delay,  if  any,  will  there  be  in  the  data  from  MARC 
tapes  as  opposed  to  the  availability  of  the  book  itself? 

Last,  but  not  least,  is  the  human  factor.  As  Sarah  Vann  has  put  it: 

However  sophisticated,  technically  superior,  and  feasible  a  centralized  in- 
formation flow  may  be,  it  seemingly  has  little  effect  unless  the  in- 
dividuals involved  in  such  a  program  change  their  present  habits  and 
agencies  modify  their  organizational  structure.  Any  plan  for  statewide 
activity  should  incorporate,  therefore,  a  balancing  of  technological 
feasibility  with  human  resource  adaptability.6 
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A  QUANTITATIVE  STUDY  OF  CATALOG  USE 

Among  people  who  are  concerned  with  the  management  of  libraries,  it  is 
now  almost  universally  accepted  that  the  traditional  manual  card  catalog  must 
sooner  or  later  be  replaced  by  an  on-line  computerized  catalog  of  some  sort. 
This  is  accepted  almost  as  an  article  of  faith;  there  is  almost  never  any 
questioning  or  disputing  of  its  inevitability.  I  have  no  intention  of  questioning 
or  disputing  its  inevitability  in  this  paper;  but  there  are  questions  regarding 
the  computerizing  of  library  catalogs  which  ought  to,  and  indeed  do,  trouble 
conscientious  library  managers.  These  are  the  crucial  questions  of  how  to 
computerize  and  when  to  computerize.  The  work  I  will  report  on  was 
prompted  mainly  by  concern  with  these  questions. 

The  notion  of  computerized  library  catalogs  has  been  with  us  for  many 
years.  Computerized  library  catalogs  were,  in  fact,  set  up  at  libraries  here  and 
there  as  far  back  as  a  dozen  or  more  years— which  means  during  the  era  of  the 
first  generation  of  large  computers.  They  operated  in  batch  mode,  of  course, 
and  on  rather  restricted  document  collections;  but  they  operated.  And,  as  the 
years  have  passed,  the  catalogs  or  indexes  of  more  and  more  document 
collections  have  been  committed  to  computers. 

The  appeal  of  computers  is  obvious.  There  is,  first  of  all,  the  speed  and 
accuracy  with  which  they  can  perform  basic  functions,  such  as  filing  in  of 
new  data,  compiling  statistics,  transcribing  data  for  human  reading,  and  trans- 
mitting data  for  use  by  other  machines.  There  is  the  ability  of  computers  to 
perform  complex  logical  searches,  at  least  on  pre-designated  elements  of  the 
stored  data.  And,  very  important,  there  is  now  the  ability  of  computers  to 
serve  numerous  users  simultaneously  at  diverse  locations,  by  means  of 
time -shared  terminals,  thus  obviating  the  need  for  the  users  to  be  in  physical 
attendance  at  the  catalog  storage  location. 

Nevertheless,  the  use  of  computerized  catalogs  today  is  still  highly 
restricted.  It  tends  to  be  confined  to  applications  where  the  document 
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collection  is  relatively  small,  where  the  catalog  information  is  very  simple  and 
limited,  where  there  is  an  unusually  high  value  attached  to  rapid  or  remote 
catalog  service,  and  where  large  computing  capacity  is  already  available  for 
purposes  unrelated  to  the  library.  This  is  because  of  the  negative  aspects  of 
computers:  the  high  cost  of  converting  existing  catalogs  to  machine-readable 
form,  the  high  cost  of  computers,  the  unavailability  of  really  large-scale 
rapid-access  memory,  and  the  limited  reasoning  capacity  of  existing  computer 
programs. 

Because  the  negative  aspects  of  catalog  computerization  have  been  par- 
ticularly serious  for  the  very  large  general  purpose  library,  of  which  the  Yale 
University  Library  is  a  prominent  example,  there  has  long  been  a  tendency  for 
management  in  these  libraries  to  regard  catalog  computerization  as  probably 
inevitable  but  clearly  remote.  Therefore,  it  could  be  dismissed  from  serious 
attention.  That  attitude  can  no  longer  be  justified.  Recent  events  have  in- 
dicated that  the  time  when  conversion  will  be  practical  for  large  libraries  may 
not  be  so  remote  after  all— indeed  may  be  only  a  few  years  away.  Events 
contributing  to  this  change  have  included:  the  steady  growth  of  rapid  memory 
capacity  of  computers,  the  falling  cost  of  computing  capacity,  the  improve- 
ment of  equipment  and  of  programs  for  remote-terminal  time-sharing,  the 
establishment  of  the  MARC  system  to  make  new  catalog  data  available  in 
machine-readable  form  at  low  cost,  the  development  of  regional  library  groups 
which  have  the  potential  to  make  existing  catalog  data  available  in  machine  - 
readable  form  at  low  cost  through  cooperative  effort,  and  the  development  of 
standard  machine  formats  which  will  make  data  interchange  possible  and 
economical. 

So  the  decision  on  when  to  computerize  the  catalog  of  the  very  large 
libraries  may  soon  become  a  matter  of  tactics,  rather  than  strategy.  At  this 
point,  the  question  of  how  to  computerize  the  very  large  catalog  is  in  need  of 
urgent  attention.  The  natural  tendency,  of  course,  would  be  to  create  a 
computerized  catalog  in  the  image  of  the  existing  manual  card  catalog,  pre- 
serving all  features  of  present-day  catalog  content  and  file  organization. 
Tradition  tends  to  be  very  strong  among  catalogers  in  large  libraries.  Yet 
tradition  must  be  resisted,  or  at  least  questioned.  Existing  card  catalogs  are 
not  necessarily  the  ultimate  in  human  wisdom  and  ingenuity.  Certainly  some 
of  the  features  in  their  design  are  attributable  to  the  inherent  limitations  of 
cards  and  card  drawers.  There  is  no  need  to  perpetuate  the  weaknesses  of 
present  catalogs  in  future  catalogs.  Before  computerizing  our  catalogs,  it 
would  be  very  desirable  for  people  in  large  libraries  to  take  a  hard  look  at 
what  they  would  want  from  an  ideal  catalog,  and  then  to  see  what  sort  of 
design  in  a  computerized  catalog  would  most  closely  approach  that  ideal.  The 
key  question  is  "What  do  we  want  from  a  library  catalog?"  One  of  our 
research  projects  at  the  Yale  University  Library  is  endeavoring  to  provide  an 
answer  to  this  question. 

The  approach  we  have  taken  is  very  direct.  We  are  trying  to  learn  what 
a  future  catalog  should  be  by  studying,  quantitatively,  what  our  library 
patrons  are  trying,  successfully  or  otherwise,  to  get  out  of  our  present  catalog. 
This  study  is  supported,  in  part,  by  the  Office  of  Education.  1  The  basic  idea 
of  a  catalog  use  study  is  not  at  all  new.  There  are  quite  a  few  such  studies 
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already  reported  in  the  literature;  most  are  master's  thesis  projects.  Unfortu- 
nately, almost  none  of  them  inspire  any  confidence  in  the  results  because  of 
gross  deficiencies  in  experimental  design,  sample  size,  or  both.  Our  own  study 
was  carefully  designed  to  anticipate  and  obviate  any  foreseeable  criticism.  It  is 
a  two-year  study  which  began  in  late  1967  and  will  be  completed  late  in 
1969. 

Our  study  attempts  to  find  out  what  our  users  want  from  a  catalog,  but 
it  does  not  stop  there.  It  also  attempts  to  find  out  the  extent  to  which  our 
present  card  catalog  satisfies  the  needs  of  the  users.  And,  furthermore,  it 
attempts  to  find  out  whether  there  are  practical  methods,  manual  or  mecha- 
nized, to  satisfy  needs  that  are  not  now  being  met.  Thus,  even  if  we  do  not 
computerize  our  catalog  for  many  years,  the  study  should  be  useful  in  perfect- 
ing our  traditional  card  catalog  in  the  interim. 

Because  the  study  is  still  in  progress,  I  am  unable  to  give  any  final 
results.  The  collection  of  data  is  more  or  less  complete,  but  many  of  the 
projected  analyses  of  the  data  have  not  yet  been  accomplished.  Therefore,  I 
will  confine  myself  mainly  to  describing  how  the  study  has  been  carried  out 
and  stating  what  we  should  be  able  to  learn  from  it.  I  will  state  some  of  our 
preliminary  findings,  but  I  must  emphasize  that  all  figures  to  be  quoted  here 
are  based  on  incomplete  data  and  are  subject  to  possible  revision  in  our  final 
report. 

The  public  catalog  of  the  Yale  University  Library  is  located  in  the  main 
entry  hall  of  the  Sterling  Memorial  Library.  It  contains  some  seven  million 
cards,  housed  in  some  7,000  file  drawers.  It  is  a  single-alphabet  catalog.  It 
contains  full  catalog  card  sets  for  the  more  than  three  million  volumes  housed 
in  Sterling  Memorial  Library  and  only  main-entry  cards  for  the  two  million 
volumes  housed  in  other  libraries  at  Yale.  Since  the  numerous  school  and 
departmental  libraries  have  more  complete  catalogs  for  their  respective  col- 
lections, users  of  the  main  catalog  are  generally  in  search  of  books  that  are 
housed  in  the  collection  at  Sterling  Memorial  Library.  The  stacks  of  Sterling 
Memorial  Library  are  open  to  all  Yale  faculty  and  students,  and  to  a  rather 
large  number  of  authorized  outside  users  of  the  Library.  The  catalog,  as  you 
can  imagine,  takes  up  a  rather  large  area,  and  is  the  scene  of  constant  activity 
throughout  the  hundred  hours  a  week  that  the  Library  is  normally  open. 

A  catalog  search  is  basically  a  word-matching  procedure.  The  searcher 
seeks  to  match  some  known  clue,  which  is  commonly  a  word  or  a  phrase  or  a 
name,  against  the  headings  in  the  file;  if  he  succeeds  in  finding  a  file  item 
which  matches  his  clue,  he  can  expect  to  find  some  associated  information  in 
the  file  (e.g.,  a  call  number)  which  is  the  object  of  his  search.  In  a  nutshell, 
the  aims  of  our  study  are  to  find  out:  1)  what  clues  the  catalog  users  possess 
when  they  begin  a  catalog  search,  2)  how  well  our  present  catalog  responds  to 
(i.e.,  matches)  the  clues  that  the  user  brings,  and  3)  whether  the  respon- 
siveness of  the  catalog  might  be  improved  through  some  change(s)  in  catalog 
design. 

We  are  finding  out  what  clues  the  users  bring  to  their  catalog  searches 
through  interviews  with  a  representative  sample  of  catalog  users.  The  inter- 
viewees are  approached  at  the  instant  that  they  reach  for  a  catalog  drawer  to 
begin  a  search;  they  are  asked  a  number  of  carefully  worked  out  questions 
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designed  to  elicit  very  precisely  what  the  searcher  is  trying  to  accomplish 
through  the  catalog  and  what  information  he  has  brought  to  the  search.  We 
also  collect  background  information  about  the  searchers  (but  we  do  not  ask 
for  their  names).  The  interviewers  are  all  trained  to  follow  a  standard  inter- 
view outline.  At  the  beginning,  the  questions  are  very  general  and  nondi- 
rective,  to  avoid  leading  of  the  subject.  ("Could  you  please  tell  me  what  you 
were  about  to  do  here  at  the  catalog  when  I  interrupted  you?")  Only  after 
the  subject  has  had  ample  opportunity  to  say  whatever  he  wants  to,  in  his 
own  way,  do  the  questions  become  more  direct  and  specific.  Clues  available  to 
the  searcher  are  recorded  in  full  detail.  If  he  carries  them  in  the  form  of  a 
printed  bibliography  or  as  handwritten  notes,  they  are  photocopied  by  the 
interviewer.  If  he  carries  them  in  his  mind,  they  are  transcribed  by  the  inter- 
viewer, taking  pains  to  determine  and  preserve  the  searcher's  personal  version 
of  the  spelling  of  author  names  and  unusual  words. 

An  average  interview  takes  about  ten  minutes;  but  it  may  take  as  little 
as  two  minutes  or  more  than  fifteen  minutes,  depending  on  the  nature  of  the 
searcher's  problem  and  the  amount  of  information  which  he  brings  to  the 
search.  When  the  interview  is  concluded,  the  subject  is  left  alone  to  carry  out 
his  search,  but  is  observed  discreetly  from  a  distance.  The  catalog  drawer 
which  he  uses  is  noted.  When  he  appears  to  have  finished,  he  is  approached 
again  and  asked  if  he  was  successful.  If  so,  the  interviewer  notes  the  call 
number(s)  of  the  item(s)  which  satisfied  the  search.  Later  on,  we  can  examine 
the  catalog  cards  for  these  call  numbers,  and  we  can  examine  the  books  them- 
selves, to  see  how  well  the  existing  catalog  matched,  and  how  well  it  might 
have  matched,  the  clues  which  the  user  had  when  he  began  his  search.  This 
follow-up  activity  to  examine  the  catalog  cards  and  the  books  they  represent 
is  considerably  less  glamorous  and  exciting  than  face-to-face  interviewing,  but 
it  is  every  bit  as  important  to  our  study  and  it  actually  takes  more  time  and 
effort  than  the  interviews. 

The  interview  program,  concluded  only  this  month,  was  conducted  over 
a  full  calendar  year.  We  gathered  data  from  some  2,000  interviews.  The  cata- 
log users  were  cooperative  beyond  our  wildest  dreams.  Fewer  than  1  percent 
of  the  people  approached  refused  to  be  interviewed— generally  it  was  because 
they  had  to  rush  off  to  a  class.  Most  interview  subjects  were  delighted  to  be 
asked  about  their  activities  and  eager  to  respond  to  all  questions.  Because  of 
the  accidents  of  random  sampling,  some  people  were  interviewed  two  or  three 
times  during  the  year,  and  they  still  remained  fully  cooperative.  To  put  it 
simply,  the  library  users  were  very  happy  to  learn  that  somebody  actually 
cared  about  them. 

At  this  point,  I  should  explain  how  the  interviewees  were  selected  in 
order  to  provide  a  representative  sample.  Long  before  we  began  any  inter- 
viewing, we  had  already  begun  collecting  gross  statistics  on  observed  traffic  in 
the  catalog  area  and  on  various  activities  which  occur  in  the  catalog  area. 
There  happen  to  be  five  different  entrances  to  our  catalog  area.  By  counting 
the  number  of  people  entering  through  each  doorway  at  various  times  on  dif- 
ferent days,  we  constructed  a  preliminary  projection  of  expected  traffic  by 
day  of  week  and  time  of  day.  We  then  decided  how  large  an  interview  sample 
we  wanted  (at  least  1  percent).  To  get  this,  we  worked  out  a  precise  interview 
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schedule  for  each  doorway  in  which  the  interview  times  and  dates  are  in  pro- 
portion to  the  expected  traffic.  Thus,  each  of  our  interviewers  (two  full  time, 
with  a  third  available  to  help  in  emergencies)  was  assigned  to  be  at  a  specific 
doorway  at  a  specific  hour  and  minute;  the  first  catalog  user  who  entered 
through  that  doorway  before  a  fixed  interval  elapsed  was  the  person  to  be 
interviewed.  Then  the  interviewer  would  go  on  to  his  or  her  next  assignment, 
which  would  generally  be  a  different  doorway.  Assignments  were  spaced  to 
allow  reasonable  time  for  completion  of  one  interview  before  starting  the 
watch  for  the  next  one.  Sometimes  no  one  would  come  through  the  doorway 
during  the  scheduled  interval  and  so  there  was  no  interview;  however,  this  is  a 
random  event  which  does  not  affect  the  value  of  the  sampling  technique. 

What  can  affect  the  value  of  the  sampling  technique  we  used  is  seasonal 
variation  in  traffic  pattern.  Therefore,  we  continued  the  gross  traffic  counting 
program  for  more  than  a  year  in  order  to  detect  such  variations.  Differences 
between  the  observed  pattern  and  the  preliminary  projection  on  which  the 
interview  scheduling  was  based  will  be  compensated  for  by  applying  appropri- 
ate weighting  factors  to  the  results  of  interviews  conducted  at  different  times 
and  times  of  the  year,  so  as  to  make  the  statistical  results  entirely  representa- 
tive of  observed  traffic. 

Having  provided  a  background  on  the  study,  we  can  now  discuss  the 
ultimate  question:  What  do  we  expect  to  get  out  of  the  study  that  can  do 
anyone  some  good? 

Let  us  start  with  our  gross  observations  of  traffic  and  other  activities  in 
the  catalog  area.  We  can  plot  traffic  by  time  of  day,  day  of  the  week,  and 
time  of  the  academic  year,  and  can  thus  produce  a  clear  picture  of  expected 
volume  and  variation  of  catalog  use.  This  can  be  of  immediate  value  to  the 
library  administration— particularly  in  planning  for  the  provision  of  reference 
assistance,  and  in  scheduling  of  catalog  maintenance— and  it  can  be  important 
in  helping  to  determine  the  peak  simultaneous  access  capacity  which  must  be 
provided  in  any  future  computerized  catalog  facility.  Of  course,  librarians  already 
know  quite  a  lot  about  traffic  patterns  from  long  years  of  experience,  so  we  do 
not  expect  any  earth-shaking  revelations  from  this  particular  result  of  the  study. 

Other  aspects  of  our  observation  of  catalog  traffic  are  more  novel.  We 
have  collected  much  information  on  the  amount  of  time  which  users  spend  at 
the  catalog.  What  proportion  of  users  spends  one  minute  per  use,  two 
minutes,  five  minutes,  fifteen  minutes,  etc.?  From  this  we  can  tell  what  kind 
of  queuing  to  expect  in  the  catalog  area,  not  only  with  the  present  level  of 
activity  but  with  increased  future  activity  as  our  user  population  grows.  This 
should  give  us  a  sort  of  yardstick  against  which  to  measure  the  performance 
of  contemplated  computerized  systems,  to  see  whether  they  are  worthy  of 
serious  consideration.  We  have  collected  extensive  data  on  the  number  of  cata- 
log cards  which  users  actually  look  at  in  the  course  of  a  catalog  search,  and 
on  the  number  of  references  which  they  tend  to  copy  from  the  catalog  cards 
during  a  search.  These  data  may  or  may  not  prove  useful  in  furthering  our 
understanding  of  the  catalog  user. 

We  have  collected  data  on  precisely  which  catalog  drawers  were  con- 
sulted by  searchers  at  times  when  traffic  was  being  observed.  This  should  tell 
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us  whether  all  catalog  drawers  tend  to  be  consulted  equally  or  whether  there 
are  high -activity  areas  and  low-activity  areas  in  the  catalog.  This  will  have  an 
important  bearing  on  the  level  of  queuing  to  be  expected  in  a  computerized 
catalog  for  any  given  memory  access  arrangement.  All  of  these  results  will  be 
based  on  very  simple  objective  observation  of  the  catalog  area— merely  count- 
ing people,  and  timing  people,  counting  their  hand  motions  in  writing  down 
references  or  flipping  cards,  and  noting  and  recording  catalog  drawer  numbers. 
These  measurements  require  no  interviewing  at  all. 

The  interview  data  will  yield  a  wealth  of  potentially  useful  results.  For 
one  thing,  they  will  add  some  useful  details  to  our  picture  of  catalog  traffic. 
Since  we  record  the  academic  status  of  persons  interviewed,  we  will  be  able  to 
describe  separate  traffic  patterns  for  students,  faculty,  staff,  and 
outsiders— and  see  whether  they  differ  significantly.  We  will  be  able  to  do  the 
same  for  newcomers  to  the  University  (students  or  faculty),  as  opposed  to 
old-timers.  We  will  be  able  to  do  the  same  for  different  departmental  affilia- 
tions or  areas  of  study. 

Secondly,  the  interview  data  will  yield  quantitative  insights  into  what  it 
is  that  catalog  users  are  seeking,  and  will  tell  us  whether  different  categories 
of  users  tend  to  bring  different  types  of  problems  to  the  catalog.  Fairly  early 
in  the  study,  it  was  observed  that  the  objectives  of  catalog  searches  tend  to 
fall  into  four  rather  distinct  categories.  One  category,  the  "document  search," 
is  where  the  user  has  a  specific  published  work  in  mind  and  is  using  the  cata- 
log in  order  to  locate  a  copy  of  that  work.  A  second  category,  imperfectly 
called  the  "author  search,"  is  where  the  user  knows  of  a  source  of  publica- 
tion—usually but  not  necessarily  an  author  or  corporate  author— and  wants  to 
find  what  works  are  available  form  that  source  (e.g.,  what  are  some  books  by 
Thomas  Mann?).  A  third  category  is  the  "subject  search,"  where  the  user 
seeks  to  identify  publications  on  a  known  abstract  topic.  The  fourth  category 
is  the  "bibliographic  search,"  where  the  user  has  no  intention  of  borrowing 
any  book,  but  is  only  interested  in  finding  the  catalog  card  for  a  known 
publication  so  that  he  may  get  some  specific  information  from  the  catalog 
card  itself  (e.g.,  to  complete  the  bibliographic  citations  in  a  paper  he  is  writ- 
ing). 

The  document  search  is  by  far  the  most  common.  Analysis  of  a  portion 
of  our  data  suggests  that  about  75  percent  of  the  uses  of  our  catalog  are  for 
the  purpose  of  locating  a  specific  known  publication  (which,  to  our  surprise, 
is  almost  always  available  in  our  collection).  The  other  three  use  categories  are 
more  or  less  equally  divided  among  the  remaining  25  percent. 

These  results  are  preliminary,  of  course.  Even  if  they  were  final,  they 
would  be  suspect,  however.  There  is  a  strong  possibility  or  presumption  that 
the  actions  of  a  library  user  are  shaped  by  the  nature  of  the  catalog  facility 
that  is  available  to  him.  Do  library  users  tend  to  accommodate  themselves  to 
what  our  catalog  can  do  very  well,  such  as  locate  known  works?  We  are 
getting  an  answer  to  this  from  a  very  innocuous  sounding  but  highly  revealing 
question  that  we  ask  in  our  interviews.  It  reveals  that  a  significant  number  of 
the  document  searches  performed  at  the  catalog  are  really  subject  searches  in 
disguise.  Presumably  there  would  be  a  smaller  proportion  of  overt  document 
searches  if  our  library  catalogs  were  better  suited  for  subject  searching.  We 
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hope  to  get  at  the  question  of  accommodation  in  yet  another  way,  by  looking 
for  any  difference  in  searching  patterns  between  newcomers  to  the  University 
and  old-timers,  or  between  newcomers  at  the  beginning  of  the  school  year  and 
later  in  the  school  year  (when  they  have  had  a  chance  to  adjust  to  reality). 

A  third,  and  also  very  important,  type  of  result  expected  from  our  inter- 
view data  will  be  the  compilations  and  analysis  of  the  search  clues  which  cata- 
log users  possess  at  the  start  of  their  searches.  By  comparing  the  clues  with 
the  information  available  in  the  retrieved  catalog  cards  and  the  documents 
they  represent,  we  can  assess  the  accuracy  of  the  clues.  For  example,  we  can 
tell  how  often  the  catalog  users  start  out  with  author  names  or  titles  that  are 
inaccurate  or  misspelled,  and  we  can  analyze  the  frequency  of  different  types 
of  inaccuracies.  This  is  fairly  important  for  designing  card  catalogs,  but  it 
could  be  crucial  for  computerized  catalogs.  Computers  make  no  concessions  to 
misspelling  unless  designers  take  great  pains  to  program  around  their  punc- 
tilious and  unyielding  accuracy.  The  data  collected  from  the  interview  program 
can  be  used  to  test  the  effectiveness  of  computer  algorithms  which  are  in- 
tended to  produce  matches  despite  inaccurate  input  from  the  searcher.  We 
have  already  made  quantitative  evaluations  of  the  effectiveness  of  two  dif- 
ferent data  compression  algorithms  described  in  the  literature  by  testing  them 
on  real  data  from  our  interview  program. 

Last,  but  by  no  means  least,  we  will  be  able  to  use  data  from  the  inter- 
views and  from  the  retrieved  catalog  cards,  and  from  the  works  corresponding 
to  those  catalog  cards,  to  seek  means  to  improve  the  quality  and  efficiency  of 
cataloging  rules  and  catalog  structure.  We  will  be  able  to  say  whether  there  are 
categories  of  data  included  on  cards  which  are  rarely  wanted,  or  categories 
which  are  frequently  wanted  but  rarely  included.  We  will  be  able  to  throw 
some  light  on  the  wisdom  of  dividing  a  catalog  into  sections  segregated  by 
date  of  publication  or  by  other  unconventional  distinctions.  We  should  learn 
whether  machine-like  subject  indexing  which  makes  use  of  the  key  words 
occurring  in  book  titles,  or  prefaces,  or  chapter  headings,  or  indexes,  etc., 
would  match  actual  user  clues  as  well  as  our  conventional  subject  indexing 
(based  on  authority  lists)  does  now,  or  whether  it  would  be  even  better. 

Of  course,  we  are  only  studying  one  library  at  one  university.  Will  our 
results  be  useful  to  people  outside  of  Yale?  We  believe  that  they  will  be;  but  I 
would  caution  in  advance  against  blind  acceptance  of  any  of  our  results  as 
universally  relevant.  There  are  bound  to  be  local  differences  among  libraries 
and  universities.  To  find  out  how  significant  these  differences  can  be,  it  would 
be  prudent  to  conduct  studies  similar  to  ours  at  a  considerable  number  of 
large  libraries  of  different  kinds.  I  was  very  gratified  to  learn  recently  that  a 
study  of  this  type  will  soon  be  undertaken  at  the  Library  of  Congress.  But 
more  studies  are  needed.  I  hope  that  they  will  not  be  long  in  coming  since  the 
computers  are  nearly  upon  us.  With  all  the  effort  that  has  been  going  into 
research  and  development  work  on  how  to  computerize  catalogs,  it  would  be 
nice  to  have  more  guidance  on  how  to  do  it  right. 
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CRITERIA  FOR  DESIGN  OF  AN  ON-LINE 

ACQUISITIONS  SYSTEM  AT 
WASHINGTON  STATE  UNIVERSITY  LIBRARY 

In  order  to  lay  the  framework  for  developing  the  criteria  for  our 
acquisitions  system,  I  think  it  would  first  be  helpful  to  describe  briefly  the 
environment  of  the  University  and  the  Library  and  the  computing  capabilities 
available.  Washington  State  University  is  a  land  grant  college  and  is  therefore 
somewhat  oriented  toward  the  agricultural  sciences  as  well  as  the  engineering 
and  physical  sciences.  The  University's  current  enrollment  is  approximately 
12,000  students  with  approximately  3,000  graduate  and  9,000  undergraduate 
students  with  the  graduate  student  population  increasing  faster  than  the 
undergraduate.  The  total  student  population  is  increasing  on  the  average  of 
about  500  students  a  year.  The  University  is  remotely  located  in  a  very  small 
town  so  that  the  student  population  on  the  campus  is  a  resident  population. 

The  Library  at  Washington  State  contains  approximately  one  million 
volumes  and  about  900,000  titles.  Our  current  standing  orders  range  in  the 
neighborhood  of  9,000  entries.  The  Library  is  organized  into  four  independent 
divisional  activities,  three  of  these  being  user  services  activities  for  the 
sciences,  the  humanities,  and  the  social  sciences,  the  fourth  being  the  technical 
services  group  which  is  providing  services  and  support  to  the  three  user 
libraries.  These  three  libraries  are  completely  independent  in  the  development 
of  procedures  for  servicing  their  clientele  and  for  the  development  of  the 
collections  in  their  respective  areas.  Under  these  three  divisional  libraries  fall 
some  twenty-seven  departmental  libraries  whose  collections  are  provided  by 
the  main  divisional  library  but  whose  staffing  is  provided  by  the  department 
involved.  Operational  policies  for  the  departmental  libraries  are  determined  by 
the  department  involved. 
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Washington  State  has  been  a  strong  leader  in  the  field  of  computer 
science  since  its  emergence  on  campus  in  1956.  We  have  a  department  of 
computer  sciences  offering  both  the  master's  and  Ph.D.  degrees.  The 
computing  center,  which  supports  this  activity  and  administrative  data  process- 
ing, uses  a  360  model  67  and  a  360  model  20. 

The  University  Library  became  deeply  involved  in  automation  in  1967. 
Prior  to  that  time  they  had  dabbled  in  some  machine  processing  of  acqui- 
sitions data.  The  Library's  decision  to  move  more  heavily  into  automation 
resulted  initially  from  growing  faculty  concern  over  the  continued  splintering 
of  both  the  collection  and  the  location  of  materials  on  the  campus.  Although 
there  is  one  consolidated  catalog  for  the  campus,  the  serial  records  informa- 
tion is  fragmented  between  the  three  divisional  libraries.  The  second  reason 
for  moving  towards  automation  was  because  existing  services  within  the 
Library  were  breaking  down  due  to  the  increased  volume  of  materials  being 
received  by  the  Library.  The  Library's  budget  had  been  steadily  expanding, 
and  there  had  been  a  corresponding  increase  in  the  collection  of  materials. 
The  systems  operated  by  the  Library  were  thus  becoming  saturated  and  in- 
creasingly less  effective.  These  systems  included  both  manual  systems  and 
semi -automated  machine  processing  systems.  It  was  at  this  point  in  1967  that 
the  position  of  systems  analyst  was  created  on  the  Library  staff,  and  I 
assumed  that  position.  We  were  installing  the  360  model  67  in  that  year  and 
looking  forward  to  time-sharing  systems  for  the  total  campus  environment  in 
the  near  future. 

Because  of  the  great  computer  capability  which  we  were  able  to  antici- 
pate, we  decided  to  design  a  system  which  would  include  terminal  operations. 
We  also  recognized  that  there  were  many  areas  within  the  Library  which  could 
be  automated.  We  felt  that  before  development  of  any  one  specific  area  could 
be  undertaken,  however,  a  total  system  design  or  at  least  a  set  of  total  system 
criteria  should  be  developed,  and  this  we  set  out  to  do. 

We  felt  that,  first  of  all,  the  various  subsystems  within  the  total  system 
would  have  to  be  compatible  with  each  other  and  that  it  would  therefore  be 
necessary  before  the  development  of  any  particular  subsystem  to  develop  a  set 
of  interface  criteria  to  provide  for  compatibility  with  other  subsystems. 

Secondly,  upon  analysis  of  total  Library  operations,  there  appeared  to 
be  many  similar  and  repetitive  tasks  being  performed  in  many  areas  of  the 
Library.  Therefore  we  decided  that  the  computer  program  system  should  be 
designed  on  a  modular  basis  and  that  most  of  these  similar  activities  within 
the  Library  should  be  written  as  sub-routines  within  and  called  from  the 
various  applications  programs  by  the  various  subsystems  as  they  were 
developed,  thus  reducing  the  total  development  time  for  the  Library.  This 
concept  of  modularity  can  pay  off  not  only  in  terms  of  total  development 
time,  but  also  in  terms  of  revision  and  maintenance  of  existing  operations. 

Thirdly,  we  realized  that  the  Library  maintained  many  redundant  files 
or  portions  of  files  in  various  locations.  Therefore  we  decided  to  reduce  the 
number  of  files  to  a  minimum  and  to  build  a  total  data  base  with  a  capability 
for  servicing  all  activities  within  the  Library  without  redundant  files.  This 
required  that  the  Library  build  its  total  system  so  that  it  could  present  to  its 


UNIVERSITY  OF 

ILLINOIS  LIBRARY 

AT  URBANA-CHAMPAIGN 


52 


THOMAS  K.  BURGESS 


users  immediate  information  about  all  of  its  holdings— which  in  turn  meant 
the  development  of  rather  sophisticated  information  retrieval  programs  to  be 
operated  from  terminals.  A  further  requirement  was  management  information. 
Too  often  libraries  are  operated  by  intuition  and  past. experience  which  are  all 
that  most  library  administrators  have  to  guide  them  in  managing  the  library. 
Therefore,  we  felt  that  any  system  devised  should  be  able  to  provide  manage- 
ment with  good  solid  data  and  statistics  concerning  its  operations  and  use. 

The  next  criterion  for  development  of  the  total  library  system  was  that 
economic  use  of  all  the  Library's  resources  should  be  made  in  the  develop- 
ment of  any  subsystem.  This  meant  that  processes  which  could  be  automated 
but  which  do  not  have  to  be  automated  should  not  be.  Also,  the  equipment 
procured  for  use  in  automated  systems  by  the  Library  should  be  as 
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multi-purposed  as  possible  so  that  it  could  be  used  in  other  subsystems.  It 
meant  further  that  activities  which  could  be  batch  processed  should  be  and 
should  not  be  placed  on-line.  Finally,  throughout  the  entire  development,  cost 
justification  and  cost  effectiveness  were  to  be  emphasized.  This  last  criterian 
required  of  course  that  the  Library  spend  more  time  and  more  money  upon 
the  development  in  order  to  achieve  efficient,  effective  operations. 

Given  this  set  of  criteria  and  a  very  generalized  plan  of  the  system 
design,  the  Library  then  began  to  build  its  individual  subsystems  (see  Figure 
1).  The  approach  was  to  develop  these  subsystems  incrementally  and  not  try 
to  build  a  total  system  at  one  time.  Although  the  analysis  and  development  of 
the  acquisitions  system  was  started  prior  to  the  development  of  the  circulation 
system,  the  circulation  system  was  the  first  subsystem  to  become  operational. 
The  circulation  system  is  an  off-line,  standard  one  card  IBM  357  circulation 
system.  It  is  built  around  a  disk  file  of  circulation  data.  Its  input  processing  is 
in  batch  mode  to  the  file.  It  is  of  the  transaction  type  in  that  each  transaction 
card  off  the  circulation  system  is  identified  by  its  transaction  code  prior  to 
the  information  being  processed  into  the  file.  The  reason  for  this  was  that  we 
felt  that  we  wanted  to  have  the  capability  of  using  the  357  equipment  for 
purposes  other  than  circulation.  Development  of  this  off-line  circulation 
system  immediately  violated  one  of  our  original  criteria,  however,  in  that  it 
does  not  make  available  immediately  information  on  Library  holdings.  This  is 
one  of  its  major  disadvantages  and  we  hope  to  correct  this  as  soon  as  desirable 
on-line  equipment  becomes  available. 
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The  decision  to  go  ahead  with  circulation  in  the  absence  of  desirable 
on-line  circulation  equipment  was  made  because  of  the  other  known  benefits 
that  could  be  gained  from  having  an  automated  circulation  system.  These 
were  improved  accuracy  of  information  on  outstanding  items,  reduced  clerical 
functions  in  preparation  of  overdue  notices  and  fine  notices,  and  the  ability  to 
provide  management  with  information  and  valid  statistics  on  the  use  of  the 
active  collection.  These  advantages  were  felt  to  far  outweigh  the  disadvantage 
of  not  having  immediate  access  to  accurately  updated  circulation  files. 

Figure  2 
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One  of  the  reasons  for  discussing  the  circulation  system  before  going 
into  the  criteria  for  the  acquisitions  system  is  to  illustrate  the  use  of  two  of 
the  total  system  design  requirements.  First  is  the  sharing  of  files.  The  circula- 
tion system  shares  a  file  of  student  names  and  addresses  with  the  registrar's 
office.  It  is  this  file  which  we  use  for  automatically  addressing  fines  and  over- 
due notices  to  the  students.  The  second  requirement  concerns  the  ability  to 
use  the  circulation  equipment  for  control  of  processes  in  both  the  acquisitions 
and  technical  services  areas  as  well  as  for  building  an  automated  time  clock 
system  for  the  management  of  student  labor  and  the  proper  calculation  and 
reporting  to  the  administration  of  student  hours  worked.  This  refers  to  the 
criterion  of  effective  utilization  of  all  Library  resources. 

The  first  criterion  in  the  design  of  the  acquisitions  system  was  to  collect 
the  necessary  data  for  each  order  at  the  beginning  of  the  acquisitions  process. 
As  currently  defined  in  our  Library,  the  acquisitions  process  begins  with  the 
release  of  the  order  request  from  the  searching  section  after  verification  of 
bibliographic  information.  At  this  point  the  data  are  immediately  entered  into 
our  in-process  file  which  is  stored  on  magnetic  disk.  A  second  criterion  for  the 
development  of  the  acquisitions  system  was  that  we  provide  for  effective  file 
management  and  for  immediate  and  continuous  updating  of  data  within  the 
files. 
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The  third  criterion  was  the  provision  for  both  terminal  operations  and 
batch  processing,  batch  processing  being  used  where  it  was  most  effective.  The 
fourth  criterion  was  the  ability  to  have  immediate  inquiry  into  the  file  from 
many  different  kinds  of  access  points  such  as  vendor,  title,  author,  publisher, 
etc. 

The  fifth  criterion  was  to  provide  for  as  much  automatic  machine 
processing  file  editing  as  possible.  This  included  editing  for  reasonableness  of 
input  information  as  well  as  for  periodic  editing  of  the  entire  file  to  determine 
if  duplicate  records  existed.  The  sixth  criterion  for  the  acquisitions  system 
called  for  the  automatic  performance  of  as  many  processes  as  could  be 
defined  which  should  not  be  on  an  on-demand  basis.  Thus,  processing  of 
records  for  determining  which  orders  are  outstanding  beyond  a  certain  allow- 
able period  of  time  should  be  done  on  an  automatic  basis.  Automatic  removal 
of  records  from  the  file  when  the  material  is  no  longer  in  the  technical 
services  area  must  also  be  provided. 

The  seventh  criterion  involves  the  development  of  management  informa- 
tion on  the  acquisitions  process.  We  judged  it  necessary  that  we  be  able  to 
develop  vendor  performance  information,  to  identify  the  length  of  time 
materials  are  on  order  and  to  supply  other  data  in  order  to  provide  both  top 
administrative  management  as  well  as  middle  management  with  information 
which  allows  them  to  more  effectively  perform  their  functions.  The  eighth 
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criterion  was  for  the  development  of  flexibility  of  procedures.  The  system 
should  have  the  capability  of  being  modified  easily  in  order  to  keep  up  with 
constantly  changing  administrative  procedures  and  to  continue  to  grow  as  the 
acquisitions  activity  grows. 

The  ninth  criterion  was  that  the  system  should  be  as  simple  to  operate 
as  possible;  terminal  functions  by  the  clerical  staff  should  be  kept  simplified. 
The  tenth  criterion  was  that  the  system  should  have  the  potential  of  growing 
so  that  the  maximum  volume  of  materials  that  can  be  handled  by  the  system 
effectively  would  be  much  larger  than  the  current  volume.  Having  developed 
the  criteria  for  the  acquisitions  subsystem  we  then  began  to  design  the  system 
(see  Figure  2). 
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The  file  was  structured  around  tagged  fields.  The  terminal  system  was 
designed  to  recognized  tagged  fields  and  to  process  the  information  accord- 
ingly. Therefore  we  designed  a  series  of  sub-routine  programs  which  could  be 
called  on  the  basis  of  the  data  tag.  The  system  currently  contains  approxi- 
mately 150  different  data  tags  and  sub-programs  which  operate  on  these  tags. 
After  developing  the  system  to  this  point,  we  then  placed  it  in  pilot  operation 
working  on  a  file  of  approximately  1 ,000  records.  After  operating  in  the  pilot 
fashion  for  approximately  six  months,  we  then  put  the  system  into  full 
operational  status.  It  was  at  this  time  that  we  began  to  build  procedures 
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which  would  chain  these  data  file  tag  programs  together  in  order  to  reduce 
the  total  amount  of  operator  keyboarding  and  operator  intervention.  Although 
it  was  possible  to  handle  most  all  of  the  acquisition  activities  of  the  exception 
type  in  the  original  system,  in  many  cases  it  was  rather  awkward.  Therefore, 
we  began  to  build  procedures  which  allowed  us  to  chain  some  of  these  opera- 
tions together  in  order  to  make  handling  of  exceptions  within  the  system 
easier. 
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We  are  still  developing  some  of  these  procedures.  At  the  same  time  we 
are  beginning  to  develop  a  design  for  a  re-structured  system  which  will  make 
the  development  of  these  procedures  still  easier.  At  this  writing  the  system  has 
been  operating  for  approximately  nine  months,  handling  all  of  the  University 
Library's  acquisitions. 

The  acquisitions  staff,  having  gone  through  some  rather  traumatic 
experiences  during  the  initial  shakedown  of  the  system  is  now  quite  pleased 
with  its  operation  and  feels  that  it  can  handle  additional  increases  in  the  book 
budget  as  they  arise. 

In  conclusion,  I  might  note  that  there  has  also  been  a  change  in  the 
design  of  operating  terminals  which  has  caused  a  corresponding  change  in  our 
original  design  (see  Figure  3).  However,  our  original  goals  are  still  being 
maintained. 
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I  would  like  to  begin  by  emphasizing  that  what  we  are  considering  is  a 
system— in  particular,  a  computer-aided  library  system.  The  system  in  this 
sense  may  be  a  technical  services  system,  a  serial  records  system,  or  a  library 
holdings  information  retrieval  system.  Each  of  these  library  systems,  when 
implemented,  will  consist  of  a  series  of  interrelated  computer  programs  which 
operate  on  a  store  of  information,  or  a  data  base.  These  programs  either  keep 
the  contained  information  current  to  reflect  the  true  status  of  the  system,  or 
provide  reports,  documents,  and  current  information  to  the  users  of  the 
system. 

Certainly  these  concepts,  updating  and  querying  a  data  base,  are  not 
new  to  the  data  processing  community.  These  concepts,  in  fact,  exist  in  every 
data  processing  organization  at  various  levels  of  sophistication.  A  simple 
example  of  such  information  processing  might  be  found  in  a  payroll  system 
involving  a  file  of  employee  information,  a  data  base,  and  a  set  of  computer 
programs  to  process  the  data.  The  data  base  in  this  case  is  updated  by  the 
addition  of  new  employees,  by  salary  or  benefit  changes,  by  deletion  of 
former  employees,  or  possibly  by  accumulation  of  year-to-date  totals  during 
processing.  The  products  of  the  current  file  would  be  the  pay  checks  for  the 
employees  and  the  reports  used  by  the  company  and  the  company  manage- 
ment. 

At  the  other  end  of  the  scale,  one  might  find  a  corporate  information 
system.  In  part  of  its  data  base  might  be  all  of  the  information  that  affects 
the  budget  of  the  corporation.  Such  data,  which  come  from  widely  varied 
sources,  must  be  constantly  updated  to  reflect  the  current  status  of  the 
budget.  The  data  must  be  available  for  regular  processing  and  for  the  manage- 
ment of  the  corporation  to  retrieve  and  correlate  as  desired.  Management  will 
then  be  able  to  "converse"  with  the  computer  to  obtain  information  stored  or 
developed  from  information  in  the  data  base  and  thus  have  the  capability  to 
explore  new  avenues  as  new  ideas  develop. 
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This  latter  capability  is  very  desirable  in  the  library  as  well  as  the 
corporation.  An  example  of  this  approach  in  the  library  is  found  in  providing 
an  untrained  library  user  with  the  capability  to  query  the  holdings  of  a  library 
by  using  author,  title,  or  subject  as  entries.  The  data  base  in  this  case  consists 
of  the  library  catalog.  The  user,  who  has  a  predefined  concept  relating  to  the 
information  for  which  he  is  searching,  should  have  the  capability  to  direct  the 
search  and  explore  different  avenues  that  may  lead  to  the  end  result,  a 
probable  source  of  information. 

These  types  of  systems  are  constructed  by  using  one  or  another  kind  of 
programming  language.  The  language  may  be  an  assembly  level  language, 
whose  instructions  closely  resemble  those  machine  functions  that  are  built 
into  the  computer,  or  a  procedural  language  such  as  FORTRAN,  COBOL, 
ALGOL,  or  PL/I.  Each  statement  in  a  procedural  language  normally  generates 
several  machine-level  instructions. 

The  programming  language  requirements  of  the  library  system,  as 
compared  to  that  of  the  corporate  information  system  are  very  similar.  For 
instance,  in  both  systems  we  must  have  the  capability  to  manipulate  large  files 
in  both  a  random  and  a  sequential  manner.  In  both  systems  we  must  be  able 
to  do  arithmetic,  and  have  flexible  facilities  to  print  reports.  If  the  system  is 
an  on-line  system,  it  is  necessary  to  have  the  ability  to  intercept  errors  and 
interrupts  so  that,  for  instance,  program  failure  caused  by  one  terminal  in  the 
system  does  not  affect  the  operation  of  the  other  terminals  using  the  same 
program.  In  addition,  for  certain  errors,  the  program  can  analyze  and  feed 
back  to  the  user  the  nature  of  the  error  that  caused  program  failure. 

The  library  system,  as  one  may  expect,  has  all  the  requirements  of  the 
corporate  system  as  well  as  some  additional  ones.  These  additional  require- 
ments are  caused  mainly  by  the  types  of  data  that  are  encountered  in  the 
library.  Outside  the  library,  one  tends  to  find  that  most  information  in  a 
computer  record  is  defined  with  a  fixed  length.  That  is,  information  such  as 
dollars,  stock  numbers,  and  often  names  have  a  fixed  length  field  set  up  both 
within  the  computer  and  on  external  storage.  Typically,  one  might  find 
defined  in  a  card,  "name"  in  columns  1  through  20,  "stock  number"  in 
columns  29  through  30,  and  "price"  in  columns  31  through  39.  Data  items 
that  do  not  vary  greatly  in  length  are  placed  into  fixed  length  fields,  and  for  a 
very  good  reason:  it  is  much  easier  to  write  programs  and  manage  the  data 
using  fixed  fields. 

The  problems  of  handling  data  become  much  more  acute  when  working 
with  library  information  such  as  is  found  is  bibliographic  records.  Authors, 
titles,  collations,  and  subjects  are  of  variable  and  unpredictable  length.  Since  a 
large  portion  of  library  programming  deals  with  such  fields,  it  is  imperative  to 
have  the  proper  tools  built  into  a  programming  language  to  manipulate  easily 
this  type  of  information.  It  is  equally  important  to  have  these  tools  so  built  in 
that  the  programmer  can  conceptualize  the  data  as  it  really  is.  For  example, 
to  the  programmer  a  title  may  be  a  string  of  characters  call  "title,"  or  it  may 
be  an  array  of  numbers  that  must  be  handled  with  arithmetic  type  statements 
and  loops.  If  the  programmer  can  work  in  terms  of  characters— that  is,  search 
for  character  patterns,  compare,  character  strings,  extract  strings  of  characters, 
insert  strings  of  characters,  and  concatenate  strings  of  characters,  rather  than 
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manipulating  arrays  of  numbers— he  will  be  more  productive  and  the  programs 
that  he  writes  will  be  more  logical  and  understandable. 

What  kind  of  capabilities  should  one  look  for  in  a  programming  language 
for  a  library  system?  Perhaps  a  representative  example  would  help  to  point 
out  which  capabilities  are  necessary  and  which  may  be  desirable.  I  would  like 
to  use  as  this  example  an  experimental  system  which  I  developed  while  at 
Washington  State  University  in  1968.  The  system  was  developed  as  a  tool  to 
test  techniques  for  retrieving  titles  from  a  computer-based  file  using  an 
imperfect  search  request.  The  research  was  directed  towards  providing  a 
library  user  with  the  ability  to  query  the  holdings  of  the  library.  The  system, 
I  think,  provides  most  of  the  facilities  necessary  in  a  programming  language 
when  it  is  used  to  develop  library  systems. 

For  a  user  of  this  system,  the  question  is:  "Is  this  title  held  by  the 
library?"  After  the  query  is  entered,  it  is  analyzed  by  the  system  which  takes 
into  account  possible  spelling  errors,  missing  or  additional  words  or  phrases, 
and  other  mistakes  such  as  capitalization  and  punctuation.  Based  upon  the 
analysis,  the  system  will  search  the  catalog  and  report  the  findings  of  the 
search  to  the  user.  The  results  of  the  search  are  either  a  list  of  "most  proba- 
ble" matches  to  the  query,  or  a  negative  reply.  The  user  can  then  accept  the 
results  or  rephrase  the  query.  An  example  of  the  query  and  the  results  is 
found  in  Figure  1 . 

The  system  consists  of  two  main  processes  which  I  would  like  to 
examine  in  some  detail  to  point  out  the  different  aspects  of  the  system  as  far 
as  programming  is  concerned.  The  first  of  these  processes  constructs  the  library 
catalog  on  a  direct  access  device.  The  second  analyzes  search  requests,  searches 
the  catalog,  and  reports  the  results  of  the  search  to  the  system  user. 

The  catalog  together  with  its  indexes,  is  built  from  examining  the  title 
in  raw  bibliographic  form.  The  input  to  the  catalog  building  phase  is  a 
machine-readable  bibliographic  record  such  as  distributed  by  the  MARC 
Project.  The  files  used  by  the  system  consist  of  two  primary  components,  the 
dictionary  and  the  catalog.  The  general  organization  of  the  files  within  the 
system  may  be  seen  in  Figure  2.  The  catalog  contains  the  complete  biblio- 
graphic citations  and  is  used  to  display  search  results  to  the  user.  The 
dictionary  component  is  used  interactively  to  formulate  the  search  request  and 
for  the  primary  phase  of  the  search  strategy.  Each  component  of  the  system  is 
assumed  to  have  entries  available  by  random  access  techniques.  Note  that  in 
the  case  of  the  dictionary  entry,  a  direct  access  address  in  this  system  must  be 
found  by  manipulating  a  string  of  characters.  In  addition  to  manipulating  the 
word  for  the  dictionary  entry,  the  programming  language  must  have  the 
facility  to  store  and  retrieve  both  fixed  length  and  variable  length  records  on  a 
direct  access  device. 

The  dictionary  in  Figure  2  contains  all  the  non-common  words  that 
appear  in  the  bibliographic  entries.  These  words  have  been  analyzed  and 
modified  to  compensate  for  spelling  and  typographical  errors.  Along  with  each 
word  entry  in  the  dictionary  is  additional  information  that  describes  the 
context  that  the  word  is  used  in,  "see"  references,  "see  also"  references,  and  a 
list  of  documents  containing  the  word  in  the  given  context.  The  context  or 
attribute  entry  describes  the  type  of  entry  in  which  the  word  was  used,  such 
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Figure  1 
QUERY   AND   SYSTEM   RESPONSE    EXAMPLES 


QUERY:   TITLE:     India's   Foreign  Policies. 

30867       0.8667       India's   Defense   and  Foreign  Policies 
END 


QUERY:   TITLE:     MIT   TECHNICAL  REPORT 

42136       1.0000       M.  I.  T.    Technical  Reports. 
END 


QUERY:     TITLE:     Les   Integrals   Eulerines. 

01862        1.0000        Les    Integrales    Eulerinnes    et    Leurs 
Applications. 

END 


QUERY:     TITLE:     Websters   Seventh  new   Collegiate 
Dictionary. 

THIS   TITLE   NOT   HELD   BY  THE    LIBRARY. 


Note:     In  the   above  examples  the  first  number  in  the 
system  response   is  the   accession  number  and 
the   second  is  the   coefficient  of  similarity  between 
the  query  title   and  the   catalog  title  as   calculated 
by  the  system. 
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Figure  2 
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as  a  title  entry  or  an  author  entry.  The  "see"  reference  points  to  a  word  to  be 
used  instead  of  the  one  in  the  search  request.  The  "see  also"  reference  points 
to  the  associated  words  to  be  used  in  addition  to  the  ones  appearing  in  the 
search  request.  Both  of  these  cross  reference  facilities  are  used  to  expand  or 
standardize  abbreviations,  and  to  aid  the  user  in  formulating  his  search  re- 
quest. Each  entry  in  the  document  list  contains  two  fields.  One  indicates  a 
document  number  that  the  word  was  used  in,  and  the  other  the  relative 
position  of  this  word  within  the  entry.  The  relative  position  within  the  entry 
is  used  in  the  algorithm  to  measure  the  degree  of  similarity  between  the 
search  request  and  a  title  in  the  catalog. 

The  catalog  component  of  the  system  provides  for  storage  of  the  catalog 
and  makes  each  catalog  record  directly  accessible.  The  catalog  directory  as 
shown  in  Figure  2,  provides  a  list  of  catalog  records  together  with  their 
physical  location  in  the  file.  The  program  must  be  able  to  manipulate  the 
document  identifier  to  yield  a  mapping  from  the  identifier  to  the  catalog 
directory.  It  must  be  able  to  manipulate  the  variable  length  catalog  record 
either  as  a  variable  length  record  or  as  a  series  of  fixed  length  records  with  a 
variable  number  of  records. 

The  dictionary  is  built  by  extracting  a  title  from  the  bibliographic 
record,  manipulating,  and  analyzing  it.  This  title  is  processed  as  follows: 

1)  All  punctuation  is  removed  from  the  title  by  serially  examining 
each  character.  Some  are  changed  to  blanks;  others  are  deleted. 

2)  Each  lower  case  alphabetic  character  is  changed  to  upper  case 
by  logically  OR'ing  it  with  a  bit  string  of  01000000  on  the  IBM  360. 

3)  The  title  is  broken  down  into  its  individual  words  and  the 
relative  position  of  these  words  is  marked.  This  is  accomplished  by 
searching  for  the  blanks  between  words. 

4)  Each  word  is  then  processed  against  a  list  of  common  words, 
and  the  common  words  are  deleted  from  the  list  of  title  words. 

5)  Each  remaining  word  is  examined  character  by  character  from 
left  to  right  and  the  abbreviated  form  of  the  word  is  constructed.  This 
abbreviated  form  is  especially  constructed  to  compensate  for  spelling 
variations. 

6)  Each  remaining  triple  (word,  document  number,  and  relative 
position)  is  then  added  to  the  dictionary. 

For  an  example,  see  Figure  3.  Note  that  the  above  procedure  involves  con- 
siderable character  string  searching,  character  string  comparing,  substring 
extraction,  character  manipulation,  character  string  concatenation,  character 
string  comparisons,  and  logical  operations.  Adding  to  the  dictionary  again 
requires  the  ability  to  read  and  update  the  direct  access  files. 

When  a  query  to  the  file  is  made,  the  search  request  title  is  processed  as 
in  steps  1-5  above.  The  dictionary  is  then  searched  for  each  of  the  remaining 
words.  The  list  of  document  number— word  position  pairs— is  retrieved  for  each 
non-common  word  found  in  the  dictionary.  Each  list  is  sorted  by  document 
number  as  the  primary  sort  key  and  secondarily  by  word  position.  Each 
document  number  in  each  list  is  then  associated  with  its  corresponding  word, 
and  the  lists  are  merged  to  form  as  an  end  result  a  reconstruction  of  the 
original  titles  as  they  appeared  after  being  processed,  as  in  steps  1-5  above. 
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Figure  3 

AN   EXAMPLE    OF   TITLE    AND  QUERY   PREPROCESSING 
PRIOR   TO   MATCHING. 
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The  search  request  list  is  paired  with  each  title  list  successively  and 
input  to  a  match/comparison  routine.  The  match  routine  computes  a  coef- 
ficient of  similarity  between  the  search  request  and  the  title.  The  coefficient  is 
a  function  of  the  number  of  matching  words,  the  order  of  the  matching  words 
and  the  relative  positions  of  the  words  within  the  titles.  Based  upon  the 
magnitude  of  the  similarity  coefficient,  the  title  is  either  rejected  or  added  to 
the  list  of  titles  to  be  considered  further. 

Phase  two  of  the  search  uses  that  list  of  titles  to  be  further  considered. 
A  comparison  is  made  among  these  titles  to  find  the  "best"  match  to  the 
search  request.  The  title  to  be  compared  to  phase  two  is  extracted  from  the 
bibliographic  record  in  the  catalog  and  is  processed  as  before  except  that 
non-common  words  are  not  deleted. 
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The  preceding  system  was  successfully  programmed  using  PL/I  level  F  in 
a  period  of  less  than  two  months.  This  short  period  of  time  for  a  system  of 
this  complexity  and  diversity  of  demands  upon  the  resources  of  a  computer  is 
attributable  to  PL/I  for  several  reasons  expanded  upon  below. 

Many  different  programming  techniques  and  operations  were  necessary 
to  accomplish  this  task.  Very  involved  character  manipulation  was  needed. 
The  ability  to  build  and  access  several  direct  access  files  using  different 
accessing  techniques  was  needed.  The  ability  to  handle  variable  length  records 
and  variable  length  data  was  necessary.  An  arithmetic  capability  was  needed  to 
calculate  similarity  coefficients,  calculate  direct  access  addresses,  and  provide 
various  counters.  It  was  necessary  to  perform  both  internal  and  external  sorts. 
PL/I  provided  the  ability  to  perform  each  of  these  in  a  direct  and  easily 
programmed  manner.  The  internal  sort  was  programmed  in  PL/I  in  about  half 
a  day. 

A  second  important  aspect  of  the  language  that  aided  in  the  con- 
struction of  the  system  was  the  ability  to  construct  and  test  small  components 
of  the  system  independently.  The  system  was  constructed  in  a  highly  modular 
manner  which,  in  addition  to  de-bugging,  provided  the  ability  to  modify 
individual  components  of  the  system.  For  instance,  the  matching  algorithm 
could  be  easily  changed  without  affecting  the  rest  of  the  system.  PL/I  as  a 
language  lends  itself  very  readily  to  modular  program  construction. 

The  speed  with  which  the  system  was  developed  was  accelerated  signifi- 
cantly by  the  excellent  diagnostic  capability  of  the  language.  The  IBM  PL/I 
implementation  provides  extensive  diagnostic  messages  and  analysis  both  at 
the  time  that  the  program  is  compiled,  and  when  the  program  is  executing. 
The  execution  time  error  handler  provides  in  addition,  the  ability  for  the 
programmer  to  diagnose  and  recover  from  likely  errors  through  the  use  of  the 
ON  statement. 

In  addition  to  the  capabilities  mentioned  above,  PL/I  provides  very 
flexible  format  control  for  printing  reports,  catalogs,  or  catalog  cards  if  so 
desired.  In  addition,  the  same  flexible  format  control  is  available  to  build 
strings  of  text  internally.  Also  of  significance  to  the  library  or  text-handling 
user  is  the  list-processing  feature  of  the  language.  This  feature  provides  a  very 
flexible  and  efficient  manner  to  handle  text  and  lists  of  unknown  length. 

To  utilize  the  flexibility  and  scope  of  the  language,  one  must  pay  a 
price.  This  price  is  probably  realized  in  terms  of  slightly  larger  programs  and 
slower  compilation  speed.  In  my  opinion,  however,  this  price  is  very  small 
when  weighed  against  the  productivity  gain  realized  by  the  library  programmer 
and  the  advantages  of  having  a  single  comprehensive  language  to  learn  and  use 
when  implementing  a  library  system. 


T.  C.  Dobb 

Assistant  Manager 

Simon  Fraser  Computing  Centre 

Burnaby,  British  Columbia 


THE  ADMINISTRATION  AND  ORGANIZATION 

OF  DATA  PROCESSING  FOR  THE  LIBRARY 
AS  VIEWED  FROM  THE  COMPUTING  CENTRE 

In  order  to  give  some  structure  to  my  paper,  I  will  preface  it  by  stating 
that  library  administration  for  automation  at  Simon  Fraser  has  passed  through 
four  phases  since  1965  and  began  a  fifth  on  May  1,  1969.  The  real  situation 
was  somewhat  more  dynamic  and  haphazard  than  I  will  suggest.  Like  most 
institutions  of  comparable  size,  our  library  reacts  to  life  rather  than  generat- 
ing it;  although  we  like  to  pretend  it  is  otherwise  when  we  are  on  public  dis- 
play. 

I  would  like  to  make  it  clear  that  while  I  will  concern  myself  mainly 
with  tracing  the  administrative  convulsions  of  the  Simon  Fraser  University 
Library  as  they  related  to  automation  and  the  Computing  Centre,  I  really 
believe  it  is  more  fruitful  to  concern  oneself  with  right  people  rather  than 
with  right  structures— mainly  because  people  do  things  and  structures  do  not. 

The  first  and  longest  phase  of  automation  (summer  1965— spring  1968) 
was  also  the  most  informal.  The  librarian  came  to  the  new  job  with  great 
physical  energy  and  considerable  enthusiasm  for  automating  library  functions 
and  he  infused  a  similar  enthusiasm  into  those  of  us  who  joined  him  in  the 
summer  of  1965.  From  the  beginning,  the  Computing  Centre,  the  offices  of 
the  registrar  and  bursar,  and  the  Library  have  shared  the  same  building.  I 
would  guess  that  this  arrangement  has  had  a  positive  effect  on  the  develop- 
ment of  automated  procedures  in  all  the  offices  mentioned,  but  since  all 
arguments  would  be  based  on  conjecture,  my  opinion  must  stand  simply  as  a 
guess.  One  happy  consequence  was  that  librarians  were  thrown  into  frequent 
contact  with  the  Computing  Centre  staff.  The  fact  that  there  were  more 
librarians  anxious  to  promote  automated  procedures  in  their  areas  than  the 
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total  number  of  Computing  Centre  staff,  and  that  the  equipment  configura- 
tion in  the  Centre  was  upgraded  very  rapidly  during  this  phase  (IBM 
1440-1401-360/40)  created  a  situation  wherein  the  Library's  aspirations 
(ignorant  but  certain)  were  not  restrained  by  either  equipment  lack  or  a  large 
and  firmly  established  Computing  Centre  administration. 

In  1965,  academic  demands  on  the  Centre  were  virtually  nonexistent,  so 
the  administrative  areas  dominated  the  machine.  The  fact  that  the  manager  of 
the  Centre  reported  to  the  registrar  gave  impetus  to  this  development.  How- 
ever, during  the  past  year,  the  Centre  has  been  the  pawn  in  a  political  struggle 
which  has  recently  been  resolved  more  or  less  to  the  satisfaction  of  the 
academic  side  of  the  house. 

The  design  and  implementation  of  the  loan  system  (September  1965) 
and  the  acquisitions  system  (April  1966)  was  accomplished  by  the  informal 
collaboration  of  a  handful  of  men.  Only  one  Simon  Fraser  University  staff 
member  was  able  to  devote  all  of  his  time  to  library  automation  problems.  He 
was  a  programmer  working  for  the  Centre.  Ideas,  whimsical  decisions,  and 
cries  for  help  were  communicated  over  coffee,  in  elevators,  anywhere  where 
two  or  more  of  Centre  and  Library  staff  happened  to  meet.  This  loose  jointed 
way  of  operating  put  a  great  strain  on  those  responsible  for  making  the 
projects  work  effectively:  library  staff,  particularly  those  working  with  loans 
and  acquisitions,  had  to  learn  a  new  terminology,  new  concepts,  and  fre- 
quently how  to  think  more  precisely  about  their  objectives.  The  same  was 
true  for  the  Centre's  staff  except  that,  generally  speaking,  they  had  already 
been  encouraged  by  their  training  to  think  with  artful  precision.  There  were 
curious  failures  in  communication  which  went  undetected  by  both  sides,  often 
with  disastrous  results.  Most  frequently  problems  arose  because  of  questions 
not  asked  and  facts  or  principles  not  volunteered.  At  the  time  it  became 
obvious  only  that  librarians  and  data  processors  could  not  learn  one  another's 
profession  casually,  and  that  because  automation  imposes  a  new  kind  of 
formalism  on  library  procedures  and  a  concomitant  need  for  all  involved 
personnel  to  be  aware  of  an  incredible  number  of  high-value  variables,  staff 
must  be  made  available  who  could  devote  all  their  time  to  short-  and 
long-range  systems  analysis  and  design. 

Our  commitments  and  ambitions  were  in  conflict  with  our  naivete  and 
limited  resources.  Specifically  problems  arouse  because  new  projects  were  put 
into  production  before  old  ones  were  de-bugged;  the  Library  made  frequent 
requests  for  small  changes  of  all  kinds;  since  there  was  nothing  built  into  the 
formal  administrative  structure  to  prevent  it,  programmers  in  the  Centre  were 
subjected  to  uncoordinated  and  random  personal  requests  from  librarians  in 
acquisitions,  serials,  loans  and  collections  who  ignored,  for  the  most  part,  the 
general  agreement  that  all  such  requests  should  go  through  the  office  of  the 
assistant  librarian  for  processing;  the  projected  marriage  of  the  acquisitions 
and  the  yet  undesigned  cataloging  system  retreated  further  and  further  into 
the  future;  a  map  catalog  project  was  started,  then  scrapped;  and  the  advent 
of  Mark  II  began  to  make  us  feel  slightly  paranoid.  In  spite  of  our  aspirations 
concerning  the  development  of  a  total  library  system,  we  were  headed  toward 
a  position  where  we  would  have  systems  which  expressed  a  kind  of 
fragmented  creativity,  but  no  total. 
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At  this  point,  the  librarian,  the  registrar,  the  bursar  and  the  manager  of 
the  Computing  Centre  decided  that  each  of  the  first  three  required  a  systems 
analyst.  A  predictable  debate  took  place  to  determine  whether  applications 
men  should  be  hired  to  acquire  data  processing  skills  or  whether  data 
processors  should  be  hired  to  acquire  applications  Skills.  The  matter  was 
further  complicated  by  the  fact  that  the  manager  of  the  Computing  Centre 
wanted  the  proposed  analysts  to  report  to  him.  He  reasoned  that  they  would 
thereby  exercise  more  efficient  control  over  the  programmers  working  in  each 
area  and  be  less  likely  to  make  promises  the  Centre  could  not  fulfill.  The 
librarian  tended  to  agree,  but  was  apprehensive  about  the  possibility  of  his 
analyst  being  taken  off  Library  projects  to  put  out  fires  in  other  areas.  For 
the  Library,  the  problem  was  solved  by  the  agreement  that  its  systems  analyst 
would  be  a  librarian.  At  that  time,  I  had  been  the  acquisitions  librarian  for 
almost  two  automated  years,  and  was  familiar  with  most  of  the  activities 
shared  by  the  Centre  and  the  Library.  In  the  spring  of  1968  I  joined  the 
Computing  Centre  staff  as  systems  analyst  for  the  Library. 

This  signalled  the  beginning  of  the  second  phase.  It  was  intended  that 
for  five  months  I  would  do  nothing  but  learn  to  program,  after  which  time  I 
would  undertake  the  duties  of  an  analyst.  But  as  is  usually  the  case  when 
there  is  some  contention  between  the  real  and  the  ideal  worlds,  the  real  world 
wins.  Almost  immediately  I  became  involved  in  coordinating  and  directing  the 
activities  of  three  programmer/analysts  and  acting  as  a  communications  link 
between  them  and  the  Library.  During  this  period  the  map  catalog,  the 
pamphlet  subject  catalog,  and  desiderata  control  system  were  implemented, 
and  preliminary  work  was  started  on  the  design  of  a  on-line  loarf  system.  The 
programmer/analyst  assigned  to  library  projects  (most  important  of  which  was 
conversion  of  all  existing  Autocoder  programs  to  PL/I)  were  able  to  work  on 
a  schedule  and  consequently  were  more  productive  than  they  had  been. 

On  the  negative  side,  the  manner  in  which  I  reported  to  the  Library 
administration  was  not  completely  satisfactory.  It  had  been  agreed  that  all 
formal  communications  would  pass  through  the  assistant  librarian  for  process- 
ing. In  the  light  of  his  long  involvement  and  interest  in  the  development  of 
automated  systems  in  the  Library,  and  the  fact  that  the  most  ambitious 
systems  had  been  implemented  in  the  processing  division,  this  decision  seemed 
to  make  a  good  deal  of  practical  sense.  However,  when  requests  for  minor 
changes  to  existing  systems  continued  to  make  exhausting  demands  on  our 
resources,  we  in  the  Computing  Centre  began  to  realize  that  what  the  Library 
required  was  a  means  of  establishing  priorities  for  all  requests  for  service 
regardless  of  departmental  origin.  Although  capable  and  willing,  the  assistant 
librarian  for  processing  was  simply  too  busy  and  the  requests  too  varied,  and 
sometimes  too  politically  loaded,  for  this  means  of  reporting  to  be  viable. 

Phase  three  started  with  the  librarian's  response  to  this  problem.  He 
established  a  library  automation  committee  with  himself  as  chairman.  Other 
members  included  his  two  assistants,  the  department  heads,  and  the  library 
systems  analyst.  The  committee  functioned  primarily  as  an  advisory  body  for 
the  librarian,  but  was  also  a  forum  where  priorities  could  be  argued  and  policy 
consolidated.  Along  with  the  establishment  of  the  committee  came  the 
decision  that  the  analyst  should  report  directly  to  the  librarian,  and  that  all 
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requests  for  Computing  Centre  service  must  bear  his  signature.  It  was  hoped 
that  this  last  would  prevent  small  but  "urgent"  requests  from  bumping  work 
currently  in  progress.  Unfortunately,  the  Library  and  Computing  Centre  staff 
were  on  such  friendly  terms  that  the  new  policy  became  subject  to 
good-natured  avoidance  by  both  sides,  and  the  whole  exercise  met  with  only 
moderate  success.  Therefore,  while  phase  three  was  typified  by  somewhat 
better  communication  between  the  Library  and  the  Centre,  and  increased  in- 
volvement of  the  library  staff  in  policy  making,  it  was  still  true  that  major 
decisions  with  respect  to  operational  and  proposed  systems  were  being  made 
by  people  who  could  not  devote  a  sufficient  amount  of  their  working  day  to 
that  activity. 

Phase  four  began  in  October  1968,  and  of  all  the  phases  this  one  most 
reflected  the  individual  character  of  the  Simon  Fraser  situation.  I  was  pro- 
moted to  assistant  manager  of  the  Centre,  and  a  programmer/analyst  from  the 
Centre  was  promoted  to  systems  analyst  for  the  Library.  Why  a  librarian 
would  be  given  an  administrative  post  in  a  Computing  Centre  is  interesting, 
but  not  pertinent  to  the  subject  of  this  paper.  More  pertinent  are  the  reasons 
for  the  reversal  of  opinion  which  resulted  in  a  data  processor,  not  a  librarian, 
being  assigned  as  the  library's  analyst.  First,  the  library  administration  felt 
that  even  if  my  new  duties  would  not  directly  concern  me  with  library 
problems,  they  would  still  have  "one  of  their  own"  in  the  Centre  to  look 
after  their  political  and  philosophic  interests.  Second,  there  was  no  librarian  in 
the  establishment  who  was  prepared  to  make  the  same  move  I  had  a  few 
months  earlier.  Third,  there  was  now  an  accumulated  body  of  knowledge  in 
the  form  of  documentation  and  experience  in  the  mind  of  the  programmer/ 
analysts  concerning  the  Library's  systems,  consequently  the  need  for  an 
interpreting  librarian  at  the  "nuts  and  bolts  level"  was  felt  to  be  less  critical 
than  it  had  been.  A  search  of  the  market  for  a  librarian /data  processor  was 
not  seriously  considered  because  of  the  above  three  reasons,  the  pressure  of 
time,  and  the  fact  that  such  people  were  known  to  be  in  short  supply.  To  give 
pragmatic  value  to  the  library's  political  point  of  view  concerning  my  new 
appointment,  I  was  asked  by  them  to  be  a  member  of  the  library  automation 
committee.  The  presence  of  two  Computing  Centre  staff  members  on  the 
library  committee  played  a  role  in  the  initiation  of  the  fifth  phase— which 
officially  began  May  1,  1969. 

Before  discussing  the  rational  underlying  our  almost  current  phase  five,  I 
would  like  to  digress  briefly  and  talk  about  methodology.  During  the  course 
of  this  past  year,  I  became  aware  of  a  basic  difference  between  the  Library 
and  the  Computing  Centre  which  had  to  do  with  their  respective  modes  of 
getting  into  production.  The  Library  tended  to  institute  production  service 
procedures  in  a  fairly  undisciplined  fashion.  Policies  and  procedures  were 
established  on  a  base  of  unexamined  assumptions.  An  example  of  one  of  the 
least  examined  is  that  "A  librarian  knows  what  his  job  is."  Another  is  that 
"You  can  not  put  a  price  on  service."  Even  if  these  two  and  their  equally 
unexamined  brethren  were  cognitive ly  meaningful,  they  would  be  false.  Never- 
theless, on  such  aphorisms  rest  a  distressingly  large  percentage  of  many 
libraries'  operation  practices. 
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Although  burdened  by  curious  anomalies  in  its  own  functioning,  the 
Computing  Centre  was  very  much  aware  of  the  fact  that  its  primary  purpose 
was  production,  and  that  production  depended  upon  the  successful  application 
of  an  established  methodology.  No  competent  data  processor  would  think  of 
putting  a  program  or  a  system  into  production  without  first  going  through  a 
set  of  carefully  prescribed  developmental  steps.  The  precise  definition  of 
objectives,  input/output  requirements,  and  record  format  and  file  designing, 
plus  systems  and  program  flowchart  preparation,  and  the  careful  examination 
of  variables  as  reflected  in  decision  tables  and  the  accumulation  of  exhaustive 
test  data,  are  all  necessary  and  accepted  steps  in  the  data  processor  method- 
ology. One  person  may  do  these  things  more  artfully  than  another;  neverthe- 
less, you  will  find  people  busy  doing  them  in  almost  any  computing  center. 

At  Simon  Fraser,  the  Library's  ardent  love  affair  with  the  Computing 
Centre  and  with  automation  generally  was,  in  my  opinion,  finally  being 
frustrated  by  the  former's  failure  to  realize  just  what  was  expected  of  it.  The 
Centre  staff  would  have  been  less  frequently  bewildered  if  the  librarians  had 
used  a  method  of  problem-solving  similar  to  their  own,  but  since  librarians  do 
not  use  such  a  method  with  any  kind  of  consistency,  the  consequences  for  us 
continued  to  be  what  they  had  always  been:  moderate  success  overlaid  by 
communications  failure  leading  to  confusion,  and  ending  too  frequently  in 
failure. 

There  were  librarians  on  the  committee  who  were  aware  of  the  problem 
and  wanted  to  see  it  solved.  The  analyst  and  I  added  the  weight  of  our 
opinion  to  theirs,  and  together  we  promoted  phase  five.  The  librarian  has 
established  a  systems  group  for  the  Library  (effective  May  1,  1969)  to  consist 
of  an  assistant  librarian  for  information  systems,  who  will  supervise  three 
systems  analysts,  and  five  clericals  (two  of  the  analysts  and  four  of  the 
clericals  to  be  hired  in  September,  1969).  A  broad  interpretation  is  to  be 
given  to  both  "information"  and  "systems":  the  former  will  include  all  in- 
formation packages  of  concern  to  the  library;  the  latter,  all  library  systems, 
manual  and  automated. 

It  is  certainly  possible  that  the  creation  of  this  group  will  be  an  answer 
to  the  two  main  faults  I  have  found  with  the  relationship  between  the  Library 
and  the  Computing  Centre:  that  is  the  absence  of  an  appropriate  operational 
and  production-supporting  methodology  in  the  Library,  and  the  lack  of  staff 
who  could  devote  their  energies  full  time  to  library  systems  development. 
However,  I  see  two  potential  dangers  in  phase  five:  one  has  to  do  with  the 
creation  of  library-based  systems  groups  in  general,  and  the  other  with  the 
viability  of  this  group  within  the  Simon  Fraser  University  Library  adminis- 
trative structure  in  particular.  I  think  it  is  very  easy  for  library -based  systems 
group  to  become  "too  heavenly-minded  to  be  of  any  earthly  use."  The  fruit- 
less search  for  the  total  system  design  and  its  associated  symmetry  can  lead 
them  on  an  interplanetary  excursion  where  decisions  concerning  one  library 
on  earth  become  increasingly  difficult  to  make,  and  production  achievements 
are  remembered  as  accomplishments  in  the  pre-historic  period.  This  situation 
might  be  avoided  if  the  systems  group  is  based  in  the  production-oriented 
Computing  Centre,  or  if  the  Library  itself  develops  an  energetic  pro- 
duction/methodology philosophy.  Should  Simon  Fraser  be  successful  in 
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developing  the  latter,  it  will  still  have  to  deal  with  problems  peculiar  to  itself: 
pessimism  has  been  expressed  by  some  Simon  Fraser  librarians  about  the 
broad  interpretation  given  "information  systems"  in  conjunction  with  the  title 
"assistant  librarian."  They  fear  that  the  position  does  not  carry  sufficient 
administrative  weight  to  be  effective  and  that  genuine  problems  will  arise  if 
either  or  both  of  the  other  two  assistant  librarians  object  to  the  systems 
assistant  having  some  measure  of  control  over  their  area.  Animosity  might 
very  quickly  narrow  the  practical  limits  of  "information  systems,"  or  at  best 
make  the  librarian  an  unwilling,  overburdened,  and  unnecessary  arbitrator  of 
contentions  between  his  assistants. 

The  present  library  systems  analyst  will  continue  to  work  for  the 
Centre,  and  it  is  anticipated  that  he  will  work  very  closely  with  the  new 
group,  and  possibly  have  a  second  desk  in  the  library  itself.  I  must  admit  that 
we  are  not  quite  sure  how  this  will  work  out,  and  neither  is  he.  A  natural  fear 
would  be  that  it  might  lead  to  a  diminution  of  his  importance  vis-a-vis  new 
developments  in  the  Library.  The  Centre  is  moving  away  from  the  team  and 
toward  a  project  concept  for  its  programming  staff.  This  will  mean  that, 
theoretically,  the  library  analyst  will  be  the  only  Computing  Centre  staff 
member  who  is  continuously  involved  with  the  Library's  business.  Hopefully, 
we  will  move  into  phase  six  before  phase  five  gets  destructive. 

As  I  think  about  phases,  administrative  structures,  and  people,  I  hold  to 
one  consolation  which  can  best  be  expressed  by  working  some  substitutions 
on  an  old  Chinese  proverb: 

If  the  wrong  people  are  in  the  right  structure, 

the  right  structure  will  work  in  the  wrong  way; 

but  if  the  right  people  are  in  the  wrong  structure, 

the  wrong  structure  will  work  in  the  right  way. 


Betty  Snell 

Simon  Fraser  Computing  Centre 
Burnaby,  British  Columbia 


PROGRAMMING  LIBRARY  APPLICATIONS  IN  PL/I 

In  February  1968,  Simon  Fraser  University  Computing  Centre  began 
extensive  use  of  PL/I.  To  best  explain  what  the  library  section  of  the 
Computing  Centre  has  done  with  PL/I  during  the  intervening  period,  I  would 
like  to  begin  by  going  back  to  1968,  explaining  the  problems  with  which  we 
were  faced,  giving  a  brief  description  of  the  systems  we  had  in  operation  at 
the  time  and  of  the  systems  we  had  planned. 

In  February  1968,  we  had  five  systems  in  operation:  acquisitions 
system,  serials  listing  system,  catalog  listing  system,  circulation  system,  and 
books  inventory  system  (Figure  1).  All  systems  had  been  programmed  in 
1401  Autocoder,  running  on  an  IBM  360/40  tape  and  disk  system  under 
emulator. 

Running  under  emulator  was  only  a  temporary  measure.  All  programs 
would  have  to  be  rewritten  to  make  effective  use  of  the  operating  system  and 
since  a  360/50  without  emulator  was  due  to  arrive  in  December  1968,  all 
programs  would  have  to  be  converted  in  ten  months. 

However,  in  most  cases  this  was  not  to  be  a  one-to-one  conversion  of 
programs.  In  most  systems  so  many  modifications  had  been  made  and 
programs  added  that  the  systems  needed  redesigning.  In  some  cases  programs 
could  be  combined;  in  others  the  systems  needed  to  be  expanded  to  allow 
greater  flexibility  and  additional  lists. 

In  addition  to  the  conversion  and  overhaul  of  existing  systems,  three 
new  major  systems  had  been  planned.  These  were  the  out-of-print  desiderata 
system,  maps  listing  system,  and  pamphlets  listing  system. 

SIMON  FRASER  UNIVERSITY  LIBRARY  APPLICATIONS 
Acquisitions  System 

The  automated  acquisitions  system  went  into  production  in  April,  1966, 
seven  months  after  the  university  opened.  Although  it  has  been  modified  and 
expanded  many  times  since  its  inception,  the  basic  design  remains  the  same. 
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Figure  1  —  System  Flowchart:    Acquisitions 
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Once  the  requests  have  been  searched,  the  following  information  is 
punched  on  cards:  purchase  order  number,  purchase  order  date,  account 
number,  estimated  time  of  arrival,  estimated  price,  Library  of  Congress  card 
number,  number  of  copies,  vendor  number,  complete  main  entry  in  Library  of 
Congress  format,  short  title,  complete  imprint,  edited  entry,  edited  title  and 
purchase  order  comments.  These  cards  or  order  decks  are  sent  to  the  comput- 
ing centre  and  serve  as  input  in  the  daily  acquisitions  system  (now  run  only 
three  times  a  week). 
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Figure  1  -  System  Flowchart:  Serials  Listing 
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Figure  1  -  System  Flowchart:  Catalog  Listing 
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The  following  fields  on  each  deck  are  checked  for  validity:  vendor 
number,  currency  code,  number  of  copies,  type  of  acquisitions,  purchase  order 
number,  amount,  account  number,  and  title  (duplication  check).  For  each 
valid  order  the  following  are  produced:  a  purchase  order,  a  purchase  order  for 
Library  of  Congress  cards,  a  blue  card  to  be  returned  when  the  book  is 
received,  an  orange  card  to  be  returned  when  the  book  is  cataloged  and  an 
expense  distribution  card.  When  the  book  is  received  the  price  is  punched  into 
the  expense  distribution  card  which  is  then  sent  to  the  accounting  depart- 
ment. An  error  listing  for  invalid  orders  and  a  supplement  to  the 
books-in-process  list  are  printed  with  each  daily  acquisitions  run.  This  supple- 
ment listing  contains  all  valid  orders  processed  for  the  week. 
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Figure  1  —  System  Flowchart:  Circulation 
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Each  week  the  books-in-process  file  is  updated  with  the  new  orders  for 
the  week,  file  maintenance  cards,  and  status  change  cards  (blue  and  orange).  A 
new  books-in-process  list  is  produced  with  separate  lists  for  acquisitions, 
continuations,  serials,  and  government  publications. 

At  the  end  of  the  month,  cataloged  orders  are  dropped  from  the 
book-in-process  file,  and  lists  of  overdue  orders  and  claiming  slips,  if  re- 
quested, are  produced.  At  present  the  acquisitions  system  is  being  studied 
with  the  aim  of  making  it  a  more  compact  and  efficient  system. 

Cataloging  Listing  System 

Once  an  order  has  been  cataloged,  the  book  circulation  card  is  punched, 
a  duplicate  card  is  sent  to  the  Computing  Centre  to  form  part  of  the  library 
catalog  files. 

The  catalog  listing  system  provides  a  master  catalog  in  classification 
number  sequence  and  in  author  and  title  sequence  every  four  months.  Supple- 
ment listings  cumulating  for  four  months  are  produced  weekly.  Lists  for 
departments  in  each  sequence  are  printed  each  month  as  well  as  when  the 
master  is  printed. 
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Figure  1  —  System  Flowchart:  Books  Inventory 
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Circulation  System 

When  a  borrower  wants  to  check  out  or  renew  a  book,  he  presents  his 
borrower  badge  (identification  card)  and  the  book  to  the  IBM  1031  operator. 
The  book  card  and  borrower  badge  are  fed  into  the  IBM  1031  badge  reader. 
The  information  in  the  badge  and  book  card  is  transferred  to  the  remote  1034 
card  punch,  and  a  circulation  card  is  punched. 

When  a  book  is  returned,  the  book  card  and  return  badge  are  fed 
through  the  1031  reader  and  a  corresponding  card  is  punched  by  the  1034. 
Cards  from  books  placed  on  reserve  are  fed  through  the  1030  system  along 
with  a  course  badge.  Thus  reserve  books  appear  on  the  circulation  master  list- 
ing as  well  as  on  separate  reserve  listing  by  course  and  by  author. 

The  above  cards  together  with  fine  payment  cards  and  fine  cancellation 
cards  are  used  to  update  the  circulation  master  file  daily.  The  following 
reports  are  produced  from  the  circulation  files:  daily— daily  transactions  list- 
ing, circulation  master  listing,  bills  and  overdue  notices,  circulation  statistics, 
and  bursar's  statistics;  weekly— reserves  by  course,  reserves  by  author,  Xerox 
reserves;  upon  request— bills  and  amounts  listings.  At  present  the  circulation 
system  is  being  redesigned  and  programmed  for  an  on-line  system. 

On-Line  Loans  System 

It  is  proposed  to  implement  the  on-line  loans  system  in  two  stages  or 
phases.  Basically  the  system  is  designed  to  facilitate  inquiries  to  the  master 
loan  file  and  to  update  this  file. 

Phase  1.  Equipment  for  Phase  1  will  include  three  2260  display  termi- 
nals, three  1031  badge/card  readers,  and  a  1034  card  punch.  The  file  will  be 
held  on  one  2311  disk  drive.  The  on-line  system  will  be  operating  from  8:00 
A.M.  until  2:00  A.M.  Two  inquiry  terminals  will  be  available  for  library  users 
and  one  for  staff  use. 

The  principal  feature  of  Phase  1  will  be  direct  inquiry  to  the  master 
loan  file  regarding  the  current  status  of  books.  This  will  render  the  master 
loan  listing  of  the  current  system  unnecessary,  with  the  exception  of  reserve 
books,  which  will  still  need  to  be  listed  at  this  stage. 

Output  from  the  1034  card  punch  will  be  used  to  update  the  master  file 
during  the  day  in  batches,  probably  every  one  or  two  hours.  After  brief  edit- 
ing, the  cards  will  be  placed  into  update  areas  on  the  master  file.  These  up- 
date areas  are  also  to  be  scanned  by  the  inquiry  program. 

Staff  members  will,  in  addition  to  making  book  status  queries,  be  able 
to  place  a  hold  on  a  book  using  the  2260  display  terminal.  Also  they  will  be 
able  to  enter  renewals  and  make  inquiries  for  billing  information.  A  100 
position  record  is  used  containing  classification  number,  author/title,  due  date, 
return  date  if  a  bill,  the  borrower  code  and  number,  the  amount  if  a  fine,  and 
special  flags  for  the  type  of  record.  The  master  loan  file  uses  tables  in  core 
and  on  disk  similiar  to  indexed  sequential  organization  (which  was  not  used 
because  of  the  large  numbers  of  legitimate  duplicate  records).  Each  track  will 
contain  twenty-eight  master  file  records  and  eight  areas  available  for  updates 
during  the  day.  The  file  is  to  be  reorganized  nightly. 
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In  accessing  file  records  during  the  2260  inquiry  program,  the  copy 
number,  volume  number  and  date  of  publication  are  ignored.  This  is  to  make 
available  to  the  user  the  status  of  as  many  copies  of  the  required  title  as 
possible. 

Communication  with  2260  display  units  is  facilitated  through  the  use  of 
an  IBM  written  set  of  assembler  modules,  PGAM;  a  PL/I  interface  to  OS/360 
GAM.  This  uses  a  series  of  CALL  statements  to  reference  various  entry  points 
in  one  module  of  the  PGAM  system,  which  is  linkage-edited  with  the  PL/I 
program. 

The  PL/I  program  must  either  consist  of  a  single  task,  or  it  must  create 
a  sub-task  for  each  display  station  with  which  it  communicates.  If  the 
program  consists  of  a  single  task,  dispatching  of  program  control  between  the 
various  display  stations  is  the  responsibility  of  the  PL/I  program.  At  the  time 
of  writing,  it  has  not  been  decided  whether  multi-tasking  or  single-tasking  will 
best  meet  the  needs  of  speed  and  core  economy. 

Phase  II.  In  Phase  II  there  will  be  an  additional  2260  display  unit,  two 
1033  printers,  and  two  1031  badge/ card  readers  (one  for  reserves,  one  for 
Xerox  reserves).  In  addition  to  the  operations  performed  in  Phase  I,  Phase  II 
will  include  direct  updating  of  the  master  loan  file  from  the  1031  readers. 

An  abbreviated  catalog  file  will  be  held  on  disk  in  order  to  be  able  to 
indicate  whether  other  copies  of  the  required  book  are  in  the  stacks.  Auto- 
matic fining  of  reserves  will  be  introduced.  A  facility  will  be  built  in  to  pre- 
vent use  of  the  library  by  those  not  possessing  valid  borrower  numbers  or  to 
exclude  particular  borrower  numbers. 

The  master  loan  file,  now  containing  reserve  books  and  Xerox  reserves, 
will  be  held  on  a  2314  disk  drive.  The  target  date  for  Phase  II  is  November 
1969. 

Library  Inventory  System 

The  library  inventory  system  is  a  by-product  of  the  catalog  and  circula- 
tion systems  designed  to  produce  a  listing  of  missing  books.  Books  on  the 
catalog  file  which  are  not  on  the  circulation  file  should  be  on  the  shelves. 

The  librarian  decides  on  the  range  of  books  to  be  checked,  and  a 
control  card  with  the  first  two  positions  of  the  beginning  classification 
number  and  the  last  classification  number  and  the  last  classification  number  is 
punched,  e.g.,  B-BC.  The  circulation  master  file  is  passed  against  the  catalog 
master  and  supplement  file  and  a  shelflist  is  produced. 

Missing  books  are  checked  off  the  list  and  cards  for  these  books  are 
punched.  The  next  day  these  cards  are  passed  against  the  new  circulation 
master  and  a  listing  of  those  books  still  missing  is  produced.  This  list  is 
checked  against  the  shelves  again  and  cards  for  those  still  missing  are  sent  to 
the  computing  centre.  Another  check  is  made  against  the  circulation  master 
and  a  final  list  of  missing  books  produced.  This  listing  is  used  for  reordering 
as  well  as  for  statistics  on  lost  books. 
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Serial  Listing  System 

Card  decks  containing  title,  holdings,  notes,  serial  number,  department 
code,  and  location  were  originally  sent  to  the  Computing  Centre  weekly.  Each 
week  these  decks  were  edited,  sorted,  passed  against  the  serials  master,  and  an 
update  listing  and  a  master  listing  produced.  Lists  by  department  were 
available  upon  request.  However,  a  more  flexible  file  maintenance  procedure 
was  necessary  since  holdings  were  constantly  changing.  And,  since  all  programs 
had  to  be  rewritten  for  conversion  anyway,  more  information  was  added  to 
each  record  and  additional  listing  programs  were  written. 

In  addition  to  the  weekly  update  and  master  listings,  month-end  lists  of 
new  titles  ordered,  new  titles  received  and  backfiles  received  are  now 
produced.  Special  listings  are  printed  on  a  request  basis.  The  content  of  each 
list  is  determined  by  the  following  variables:  subjects  (up  to  thirty-five), 
publisher  type,  class,  form,  special  collections,  location,  status  of  order,  status 
of  journal,  and  department  code  (up  to  nine).  One  card  is  coded  for  each 
separate  list. 

Out-Of-Print  Desiderata  System 

Once  a  title  has  been  searched  and  the  book  found  to  be  out  of  print, 
the  book  request  card  and  bibliographic  information  is  sent  to  the  out-of-print 
unit  of  acquisitions.  A  slip  containing  a  dummy  purchase  order  number, 
estimated  price,  country  code,  account  number,  number  of  copies  and 
volumes,  up  to  ten  subject  codes,  and  any  desired  comment  is  attached  to  the 
request  card.  From  all  of  this  information,  a  deck  of  cards  is  punched.  These 
decks  are  sent  to  the  Computing  Centre  weekly. 

The  decks  are  sorted,  edited,  and  a  tape  record  produced.  This  tape  is 
used  to  update  the  master  file.  Upon  request,  desiderata  slips  are  produced  on 
8H"  x  3H"  four-part  forms.  A  card  containing  country  code  and  up  to  ten 
subject  codes  determines  each  list.  Up  to  ten  lists  can  be  produced  weekly. 

When  a  quotation  for  a  book  is  received,  the  vendor  number  and  actual 
price  are  punched  into  the  deletion  card  (first  card  of  deck).  If  for  any  other 
reason  a  title  should  be  deleted,  a  D  is  punched  in  the  vendor  number  field  of 
the  deletion  card.  Deletion  cards  are  sent  to  the  Computing  Centre  weekly. 

The  following  reports  are  produced  weekly:  master  listing  and  statistical 
report  by  account,  or  supplement  listing,  deletion  statistical  reports  by  vendor 
and  account,  and  desiderata  slips. 


Pamphlet  Listing  System 

The  information  necessary  to  list  a  pamphlet  is  gathered  and  punched 
on  a  deck  of  cards.  Each  card  in  the  deck  carries  an  identification  or  deck 
number,  a  card  type  and  a  card  code.  This  allows  easy  sorting  into  sequence 
and  checking  for  duplicates.  Card  type  one  is  the  general  information  card  and 
carries  the  file  maintenance  code  (A-addition,  D-deletion,  C-change),  quality 
code  (indicating  whether  or  not  the  pamphlet  is  ephemeral),  publication  date, 
call  number  and  location.  Card  type  two  is  the  subject  card.  There  may  be  a 
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maximum  of  ninety -nine  subject  cards  per  deck,  meaning  that  the  information 
for  a  pamphlet  may  appear  under  as  many  as  ninety -nine  different  subject 
headings.  Card  type  three  is  the  title  card,  four  the  entry  card,  and  five  the 
imprint  card.  There  may  be  up  to  two  of  each  of  these.  Three  times  a  year 
these  decks  are  sent  to  the  Computing  Centre,  sorted,  edited  and  one  variable 
length  disk  record  per  subject  code  produced.  This  file  is  sorted  by  title 
within  subject  and  used  to  update  the  master  file.  The  master  file  is  listed, 
and  an  index  to  the  list  produced. 

Maps  Listing  System 

The  maps  listing  system  is  similar  to  the  pamphlet  listing  system.  Both 
use  "strictly  variable  length"  records  and  both  use  exploded  files.  The  maps 
system  creates  one  variable  length  area  record  from  the  information  contained 
on  card  decks  and  as  many  subject  records  as  there  are  subject  codes  per 
deck. 

The  area  file  and  the  subject  file  are  updated  and  listed  every  four 
months.  The  area  master  file  is  sorted  by  alphabetic-area  sequence  also. 

PL/I 

All  in  all,  over  ninety  major  programs  were  originally  written  in  PL/I, 
tested,  documented  and  put  into  production  in  one  year.  This  figure  does  not 
count  "one-shot"  jobs  such  as  programs  to  convert  1401  files.  Moreover,  these 
programs  were  written  by  three  programmers  who  had  no  previous  PL/I 
experience.  Only  one  had  a  PL/I  course,  and  this  was  at  the  time  of  the  first 
version  of  PL/I. 

Simon  Fraser  University  was  the  first  major  installation  in  the  Van- 
couver area  to  use  PL/I.  Thus  it  was  often  difficult  to  get  direct  answers  to 
questions  regarding  programming  problems.  But  with  time  and  experience 
these  problems  have  disappeared.  IBM  worked  out  many  of  the  bugs  and  fixed 
them  in  later  releases.  However,  the  new  releases  have  posed  a  problem  in 
some  cases.  Program  statements  which  would  compile  on  earlier  releases  now 
produce  warning  and  error  messages  when  recompiled  under  the  newer 
releases.  In  spite  of  all  of  the  problems,  the  job  was  done.  On  the  average  a 
program  was  written,  compiled,  tested,  documented  and  put  into  production 
in  less  than  two  weeks.  And  in  many  cases  system  design  and  program  revision 
are  included  in  this  time.  I  think  that  this  short  implementation  time  can  best 
be  explained  by  taking  a  look  at  PL/I  itself. 

PL/I  is  a  high-level  programming  language  designed  for  both  commercial 
and  scientific  applications  and  for  real-time  and  systems  applications.  Although 
it  looks  like  a  combination  of  FORTRAN,  (a  scientific  programming  language), 
and  COBOL,  (a  commercial  programming  language),  it  is  much  more  flexible 
than  either. 

I  do  not  want  to  go  into  a  detailed  comparison  of  PL/I  and  COBOL.  For 
the  average  job,  either  language  will  do.  However,  I  think  PL/I  is  more  flexible 
and  faster  to  code  and  to  de-bug.  Moreover,  release  16  and  version  4  support 
multi-tasking  which  allows  simultaneous  service  to  remote  terminals  for  on-line 
systems. 
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Many  features  of  PL/I  contribute  toward  making  it  an  easy  language  to 
learn  and  to  use.  First,  it  is  not  necessary  to  know  all  aspects  of  PL/I  to  write 
a  program.  You  may  use  sub-sets  of  PL/I  and  ignore  other  features  of  the 
language.  As  always  there  are  many  ways  to  write  a  routine  to  do  a  specific 
task,  some  more  costly  in  core  space  and  running  time  than  others,  and  in 
PL/I  there  is  usually  at  least  one  method  which  is  easy  on  the  programmer. 
Built-in  functions,  default  attributes,  free  format,  and  sophisticated  control 
statements  save  the  programmer  much  tedious  coding.  Liberal  use  of  com- 
ments makes  programs  easy  to  follow. 

Most  programming  jobs  for  the  library  consist  of  routines  for  the 
following:  1)  editing  cards/ card  decks  and  creating  tape/disk  records;  2)  up- 
dating and  listing  files;  and  3)  producing  statistical  reports. 

I  will  give  a  few  examples  of  these  routines  in  PL/I.  The  first  two  are 
not  meant  to  be  complete  programs,  nor  are  they  meant  to  be  the  best 
methods  for  handling  the  job;  they  do  however,  work. 

If  we  consider  a  serials  card  deck  as  shown  in  Figure  2  we  will  first  need 
routines  to  check  that  the  serial  number  or  ID  number,  card  type,  and  card 
code  are  numeric,  and  that  the  subject  field  and  title  are  not  blank.  Input  will 
be  in  sequence:  serial  number-card  type-card  code.  If  the  above  information  is 
all  right  we  will  create  a  variable  length  tape  record,  as  shown  in  Figure  3. 
Otherwise  we  will  print  the  appropriate  error  message  and  bypass  the  rest  of 
the  deck. 

To  begin,  it  is  not  necessary  to  define  or  declare  the  card  input  as  long 
as  one  uses  the  default  file  name  SYSIN.  Next  we  need  an  input  area  for  the 
card  file.  We  can  set  up  a  structure  as  follows  in  Figure  4. 

Let  us  consider  another  example:  suppose  on  our  out-of-print  master  file 
we  carry  account  number,  estimated  price,  and  a  field  indicating  whether  or 
not  a  desiderata  slip  has  been  sent  out  for  each  title.  We  want  to  produce  a 
report.  There  are  fifty-three  different  accounts,  so  the  first  thing  we  do  is  set 
up  arrays  for  account  numbers  and  for  account  names,  each  containing 
fifty-three  elements.  Then  we  set  up  a  two-dimensional  array  53  x  4  to 
contain  the  variable  information.  A  separate  array  four  elements  long  may  be 
set  up  for  totals.  Since  the  account  numbers  range  from  901-999,  a  cross 
reference  table  ninety-nine  elements  long  can  be  set  up  to  give  the  correspond- 
ing row  in  the  two-dimensional  array.  For  example,  904  is  the  second  account 
to  be  listed,  so  the  fourth  element  in  the  ninety-nine  element  array  will  be  2. 
Zeros  can  be  used  for  cases  where  there  is  no  account  number.  For  example, 
there  is  no  account  number  902;  so  the  second  element  in  the  ninety-nine 
element  array  will  be  zero.  Figure  5  is  an  example  of  how  this  might  be 
programed. 

Before  going  on  to  my  last  example,  I  would  like  to  discuss  our  use  of 
variable  length  records.  First  it  was  decided  to  use  variable  length  records 
wherever  it  was  necessary  to  carry  complete  information  but  where  the 
amount  of  this  information  could  vary  greatly.  Variable  length  records  make 
more  efficient  use  of  storage  space  (tape/disk)  and  hence  allow  faster  time  to 
read  the  entire  file. 
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Figure  4  —  Structure  Set-up  and  Program 
of  an  Input  Area  for  the  Card  File 


••!•    C    INAKC A. SUfJIl  I-    •    •    THfN    0"; 
•UT  rnin 'SUHJFCT  ceo*    MSSINC  «-ii 

IN4KH.SE"  1»L  •MMRF  II  I: 
(iC    TO    HfcJfCT; 


IF    CAKO.TrPE-'i1    AND    DATA-I».OI' 


7ECIA<E    TAPEtiUr    FILE    OUTPUT    RFC01') 
UECLA4F  I  OUTAREA. 

SE»IAL«  CHAK 

FILE  HAINT 

»U"L    TVPF 

CLASS 

FC»1 

SPEC    COIL 
REPORT* 
SMJSIS) 

LUC  AT  IUN 

iTAT.JIJJHNAL 
OfcPT 


till    TO     REA 


PE-M«     THEN    CU 


HJUTKIVM 


(  7?OI  ;/*ri  Tt 


A8LF,  I.44I-OATA; 


This  will  move  all   fields  with  SOM 
name    fro*    INAREA   to   0UTAREA 


TM.KOUNTEI«l*l•^l): 


•KITE    FILE    ITAPEDUT)    FROM    IOUTAKEA2); 

ein: 

KFl:          FORMAT ISKIPI2I.COL I IOI.A.AI: 


The  basic  format  of  variable  length  records  is  as  follows:  a  fixed  portion 
containing  general  information,  a  counter  for  each  variable  length  field,  and 
variable  length  fields;  however,  the  variable  length  fields  themselves  may  differ 
in  format.  The  next  sample  program  will  show  how  to  create  two  different 
kinds  of  variable  length  records  from  a  serials  card  deck  and  two  different 
ways  to  list  these  records. 

The  first  method  adds  fixed-length  (sixty  characters)  trailers  to  the  fixed 
portion  of  the  record,  one  trailer  for  each  title,  holdings,  or  notes  card.  This  is 
the  method  we  use  in  our  serials  system.  The  second  method  adds  exactly  as 
much  information  to  the  fixed  portion  of  the  record  as  appeared  on  the  cards. 
For  example,  if  the  title  was  only  forty -three  characters  long,  then  only 
forty-three  characters  would  be  stored  on  tape  rather  than  sixty. 

The  first  method  allows  us  to  list  sixty  characters  a  line  very  simply. 
With  the  second  method,  more  complicated  print  routines  must  be  used  in 
order  to  avoid  splitting  words  at  the  end  of  each  print  line. 
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Figure  4  (continued) 


DECLARE  1  INAREA, 

2    SERIAL*  CHARI9I, 

Z    CARD    TYPE  CHARI  II, 

2    CARO.CODE  CHAR  I II. 

2    FILE.MAINT  CHARI1). 

2   PUBL    TYPE  CHARI II, 

2    CLASS  CHAR  II  I, 

2   FORM  CHARI1I , 

2    SPEC. COLL  CHARI II, 

2    REPORT*  CHAR  111, 

2    SUBJSI5I  CHARI II , 

2    SPARE  CHAM  II, 

2    LOCATION  CHAR(l), 

2    STAT_OROE*  CHARI  II. 

2    STAT.JOURNAL  CHARI1I, 

2   DF.PT  CHARI3I, 

2   EXTRAS  CHAR  I  51)  ; 
/• 

THIS    ALLOMS    US    TO    ACCESS    EACH    FIF.LO    ON    CARD   TYPE    I    SEPARATELY.       FIR 

ALL    REMAINING   CARDS    ME    NEE!)  ONLY    DECLARE    AN    ARFA    60    CHARACTERS    LONG 
BEGINNING    IN    COL.     13.    ME    MAY    DO    THIS    BY    MEANS    OF    AN    OVERLAY    AS 
FOLLOMS: 

DCL    DATA    CHARI60I     DEFINED    INAREA    P1SI13I: 
/••THUS    ALL    CARDS    CAN    B€    READ    INTO    THE    SAME    ARFA    -    INAREA 

•  / 
/••SET    UP    ANO    INIATIALIZE    ALL    FIELDS    TO    BE    USED    LATER 

•/ 

READ:     READ    FILE    ISYSIN)     INTO    I  INAREA); 
/••IS    THIS    IHE    FIRST    CARD? 

•/ 

IF  FIRST-1  THEN  DO  ;  1 
FIRST«O; 

PR£VlnUS»«INAREA.  SERIAL*!/*  NFFDEf)  TO  CHECK  FOR  FNO  OF     •/ 
GO  TO  START;  /»  !>ECK        •/ 

END; 
/••ARE    ME    AT    THE    BEGINNING    JF    A    NEK    DECK? 

*/ 

IF    INAREA. SERIAL*    >    PREVIOUS*    THFN    GO   Ttl    FND_nF_OFt<  ; 
/••ARE    *f.    REJECTING    THIS    DECK? 

•/ 

IF    CHECK^REJECT"    THE1*   GO    TO    KEAT; 
/••IS    SERIAL    NUMBER    NUMERIC? 

•  / 
START:             DO   I  «1    TO   9;                          ,                . 

IF    SUBSTRI INAREA. SERIAL*, I. IT   <    'O'^THEN    DOS 

PUT    EOITI*  INVAL  ID    SEKIAL*    -     •  ,  INAREA  .SER  I AL  *  I 

IRIRFlll;     /•    RFMOTE    FORMAT    STATEMENT  »/ 

GO   TO  REJECT; 

END; 
END: 
/••ARE    CAKO   TYPE    AND   CARD  CODE    NUMERIC? 

«/ 
IF    CARO_TYPE    <    '0«     I    CARD_COnO    <    • !)  •     THFN    00; 

PUT     EOITI  •  INVALID    CARO    TYPF    OR    CARD    CODE    FOR     «, 

INARFA.SEiUAL*)  IPIRF1  I  I; 
GO    TO   KEJFCT; 

FNt>; 

/••is  THERE  AT  LEAST  ONE  SUBJECT  CODE? 


If  the  condition  for  the  IF-THEN  D0 
does  not  hold  then  go  to  the 
corresponding  END  statement 


SUBSTR(X,I,J)  is  a  reference  to  field  X 
starting  in  position  I,  J  characters 
long 

The  collating  sequence  is  special 
characters  <  blanks  <  alphabetics  4. 
numbers.   Thus  anything  0  is  not 
numeric 
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Figure  5  —  Program  Containing  Account  Number,  Account  Names, 
Variable  Information,  and  Totals 


OECLAKE    ACCTNOSl 53)     PIC' 999'     INIT 

((  11*90  P,(  1)  '904',  (  I)  '905'  ,(  1)  '906'  til)  '907'  ,  i 


Cl)'916'     (D'9171     (1) '918'  ,UP919'  ,(1)'920 
I1)I922I     (D'9231     (  1 )  •  924  '  ,  (  1 )  '923  '  ,  (  1 )  •  930 
UP940'     UP942'     mi9**«,U)">46lt  Cl)«95fJ 
m'952'     (1P9601     (  1 )  '  965'  ,  (  I  )  '970  '  t  i  1  )  •  9  75'  ,  ( I  ) 
(1P9791     m'9801     (  1)  '932'i  (  1)  '98't'i  (  1)  '916'  ,(  1) 
(IP  988'  ,(IP989«  i  (I)  '990'  ,  (1)  '991' ,  (1  P99?',  (1) 
(1P994',<  1)  «V95«  ,(  1)  '996*  , (  1 )  ' 997 •  ,  1 1 ) ' 999'  ) ; 
DECLARE    ACCT NAMES (53)    CHAR(?3)     IN  IT 
til)' ECONOMICS    ANO    COMMERCE 
(  1) 'MEDIEVAL 
(I)1  ENGLISH 
UP  SHAKESPEARE 
CD'CONTEMP    LIT    COLLECTION 
(1P17TH   CENTURY 
(1)' 13TH   CENTURY 
C I)  'GEOGRAPHY 
(I )• COMMONWEALTH 
(1P19TH    CENTURY    BRIT. 

( i )  •  19TH  :ENTURY  u.  S.A. 

(1)'20TH    CENTURY    BRIT  . 

(1»'20TH    CENTURY    U.S.A. 

(  1)  'ENGLISH   LANGUAGC- 

(l)1 MOD    LANG-FRENCH 

(l)«  -GERMAN 

(IP  -RUSSIAN 

(ll«  -SPANISH 

(I)1  -LINGUISTICS 

UP  -OTHER 

(!>•  -LIT 

(  D'PHILDSOPHY 

(1  J'P.S.A. 

(1)' PSYCHOLOGY 

(D'PRUF    FOUND    CENTRE 

(ll'SUCIAL    G    PHIL    FOUND 

(1) 'BEHAVI ORAL    SCIENCE    FOUM 

(1) 'PHYSICAL    DEVELOPMENT 

(U  'COMMUNICAT  IONS-FINE    ART 

«!)•  -PERF    ART 

(1)'  -COMHUNIC 

JD'BIOLCGICAL    SCIENCES 

C  1) 'CHEMISTRY 

II) 'MATHEMATICS 

tl)' PHYSICS 

(1) 'LIBRARY-COLLECTION 

(1)'  -LIBRARY 

11)'  -NAT    BI3LIOGRAPH 

Cl)'  -HUMANITIES 

(1)'  -SOCIAL    SCIENCES 

(I)'  -SCIENCE 

(IP  -MAPS 

(1  PHISTCRY-LAT     AMERICA 

(  1)  •  -CANADA 

(1)'  -U.S.A. 

(1)'  -AFRICA 

(  1)  '  -NEAR    EAST 

(1)'  -FRANCE 


921  ' 
935' 
951' 
97rt' 
93"/1 
993' 
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Figure  5  (continued) 


(  i)  • 
(i  )• 


-GERMANY 
-U.S.S.R. 
-CRT  BRITAIN 
-OTHER 


/**   SET  UP 


1  1  )• 

(1  )'  OTHERS 

CROSS    REFERENCE    TA3LE 


OCL    TA8LE(99)    PIC'99'     INIT 

(  (D'Ol1  ,<2)(l  )'00«  ,(1  )'D2',  (1)  '03',  (1)  '04',  (  1)'05',<  1  )'06«, 
m'07'.C  IJ'OS'.t  1)  'OO'il  I)1  09"  ,  U)'10'  ,  (l)'ll'  ,  d)'12'  , 
(1)'13SU  )'14',I  1)'15',  (  1)  'If.',  (  1)  '17',(  2)'  1C'  ,(  1)  'I')'  , 
Jl)'20«  ,(1) '21'  ,13)  (l)'OO'  ,  (1  )'22'  ,  (l)'OO', (1 ) '?3 ' , 
(4)(  1)'00',(  1)  '24', (4)  (  1J  '00'  ,(  1)  '25'  ,(1)  'CO'  ,  (1)  «26'  , 
(1  J'OO1  ,  (I) '27',  (l)'OO',  (1  )'2'3«,  (3)1  1)'00',(  1)  '2V  ,(  1)  «30«, 
( 1)  '31' t(7) ( 1)  '00' ,11) '32'  f<4)  11  )'OC' , (1  )«33«, (4  J (1 J'OO  ', 
(1)  '3V.  (*)(  1)«00.'.(  1)'351,(2)(  1)  'OO'.J  1)  '36'  ,  (  I)  •  37'  , 
111*38*  iID'OO'i  (l)'39(t  (D'OOS  ( 1  >HO't  I  1)  '00',  (  1)  '41  • , 
(  1)  '42«.{  1)  '43'  <(  1)  '4'.'  ,(1  )'45«  ,  11  )«46«  ,(1)'47«  ,  (1  )«43«  , 
(1  )'49«,  (1  )'50', (  l)'51f, (  I)'i2', (  1) 'OO'.r  I)  '53') ; 
/**    SET    UP    T'.VO-DIf-'Ef<SIONAL    ARRAY    FOR   VARIABLES 


OCL    ARRAY(53,4)    OEC(6,2)     IN  I  Tt  ( 2 55) 0 )  ; 
OCL    TOTALS!'*)          OEC(«.2)     INIT(Ct)O); 
/**    DECLARE     INPUT    FILE    AND    INPUT    AREA 
READ:    READ    FILE    (MASTER)     INTO    (INAREA); 

J=SUBST;*UCCT.2  ,2)  ;       /**PICK    UP    LAST     H.'P    POSITIONS    DF    ACCTfi 
I  =  TABLE( J)  ; 

IF    1=0    THEN    1=53:  /**IF    NO    SUCH    ACCT&   PUT     IT    IN     'OTHERS' 

ARRAYII  ,1)=APRAY(I  ,!)  +  !;     /*<=AnO    1     TO    f'O.    TULF.S    ON    MASTER 
ARRAY  t  I,2)=APRAY{  1 ,  2  H-ESTPP.  ICE  ;     /<:*ADO    ESTIMATED    AfidUNT 


IF 


THE    T  ITLE     IS    ON 


CN_SEA:^CH=1  THEN  DO; 
ARRAYd  ,3)=ARRAY(  I  , 
ARRAY(],4)  =  ARRAY(  I,  4)+  ESTP?.  ICE  ; 

ENO; 

GO  TO  READ; 

/****  WHEN  E.MD  CF  FILE   IS  REACHED  ON  THE  MASTER  TAPE 
GO  INTO  THE  FOLLOWING  PRINT  ROUT  INF 

DO    1=1    TO    53; 

PUT    EIHTUCCTNOSU)  ,ACCTNAMES(  I)  ,(ARRAY(  I,*)) 
(COL(23),P'999',X(5),A,XI  l),P'2?Z,ZZ< 

P'Z2Z,ZZZV.99',X(6),P«ZZZ.ZZ9',X( 5),P  'ZZZ , ZZ Z V. 99< 
END; 
/****    CALCULATE    AND   PRINT    TOTALS 

00    1=1    TO    4; 
DO   J=l    TO    53: 

TOTALS(I)=TOTAL( I ) +ARRAY { J, I ) ; 
END; 

END: 
PUT  EDITC  TOTALS'  ,  (TOT  ALS  (  *)  )  )  (SK  IP  (  2  ) ,  CPL  (43  ) ,  A,  CHL  (  61 ) , 

P'ZZZ,ZZ9«,X(2),?'ZZ,ZZZ,ZZZV.9P'  ,X(6),P' ZZZ.ZZ9'  , 
X(2),P'ZZ,ZZZ,ZZZV.99«  )  ; 


*/ 


*/ 
*/ 
*/ 
*/ 


*/ 


*/ 


*/ 


Stephen  R.  Salmon 

Assistant  Director  for  Processing  Services 

Library  of  Congress 


DEVELOPMENT  OF  THE  CARD-AUTOMATED 

REPRODUCTION  AND  DISTRIBUTION  SYSTEM 

(CARDS)  AT  THE  LIBRARY  OF  CONGRESS 

Most  of  you  probably  think  of  the  Library  of  Congress  Card  Division  as 
a  place  from  which  you  get  a  lot  of  cards— or  from  which  you  do  not  get  a  lot 
of  cards.  In  a  way,  these  are  the  two  reasons  why  the  Library  is  now  engaged 
in  a  full-scale  effort  to  automate  the  card  division:  there  are  a  lot  of  cards 
involved,  and  a  lot  of  other  things— that  is,  to  say,  there  is  more  than  enough 
volume  to  make  automation  feasible  and  desirable— and  not  enough  cards  have 
been  getting  to  libraries  quickly  enough. 

Without  actually  seeing  the  day -by-day  operations  of  the  card  division,  it 
may  be  difficult  for  you  to  appreciate  its  complexity,  but  a  few  statistics  will 
convey  the  key  fact  that  the  enterprise  is  a  large  one.  It  is  large  not  only  in 
terms  of  the  number  of  cards  involved  (last  year  the  division  distributed  over 
110  million  cards,  or  about  a  thousand  cards  every  minute  of  every  working 
day,  and  cards  for  almost  five  million  separate  titles  are  in  stock)  but  also  in 
terms  of  the  number  of  orders  received— about  50,000  every  day.  It  is  large  in 
terms  of  the  number  of  people  involved— almost  500  people  currently  serve  on 
the  staff— and  in  the  amount  of  space  required  for  its  activities— approximately 
an  acre.  It  also  has  a  large  budget— over  seven  million  dollars  this  fiscal  year. 
Finally  and  most  importantly,  it  is  large  in  terms  of  its  significance  to  the 
profession:  over  25,000  libraries  around  the  world  depend  on  its  services. 

The  division  has  been  facing  increasingly  large  problems  as  well,  how- 
ever. An  acre  of  space  is  not  as  large  as  it  sounds,  and  as  the  Library  catalogs 
more  and  more  titles  each  year,  the  card  division  must  print  and  store  more 
and  more  titles.  This  means  that  fewer  and  fewer  copies  of  each  title  can  be 
stocked,  and  therefore  the  persons  filling  card  orders  find  more  and  more  often 
that  when  they  get  to  a  drawer  of  cards  to  fill  an  order,  the  stock  has  been 
exhausted.  This  now  happens  30  to  40  percent  of  the  time,  and  each  time  it 
happens  the  order  must  be  returned  or  held  until  more  stock  can  be  printed. 
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The  division  has  also  faced  other  problems:  rising  costs  (in  this  case  not 
only  increased  staff  costs  but  increasing  printing  costs),  and  a  chronic  problem 
of  recruiting  and  retaining  adequate  staff.  Steadily  rising  demands  for  its 
services  coupled  with  significant  fluctuations  in  demand  from  day  to  day  and 
from  year  to  year  have  also  contributed  to  the  growing  inefficiencies  of  a 
purely  manual  system. 

For  all  of  these  reasons,  the  Library  began  some  time  ago  to  investigate 
the  possibility  of  automating  the  card  division's  operations.  Analysis  indicated 
that  it  was  particularly  susceptible  to  automation,  since  most  of  the  opera- 
tions are  repetitive  and  many  of  them  are  clerical.  There  were  obvious  areas 
where  mechanization  could  be  immediately  effective:  the  arranging  unit,  for 
example,  where  sixty-one  people  manually  arranged  orders  either  in  alpha- 
betical order  or  in  numerical  order,  and  the  billing  unit,  where  thirty-seven 
people  not  only  checked  the  work  of  the  persons  filling  orders  but  manually 
prepared  bills.  What  was  not  so  obvious  at  first  but  which  later  became 
apparent  was  that  the  central  problem  lay  in  the  stock  itself,  for  as  long  as  it 
was  necessary  to  maintain  a  large  inventory  of  catalog  cards  and  fill  orders 
manually  from  this  stock,  many  of  the  most  serious  problems— space,  staffing 
and  the  out-of-stock  situation— would  remain  unsolved.  If,  on  the  other  hand, 
we  could  eliminate  the  inventory  and  print  card  copies  automatically,  on 
demand,  we  could  solve  most  of  these  problems  and  at  the  same  time  improve 
both  the  speed  and  efficiency  of  the  division's  services. 

The  project  divided  naturally  into  two  parts,  which  (inevitably)  came  to 
be  called  Phase  I  and  Phase  II.  Phase  I  included  the  things  we  could  do 
immediately,  primarily  the  necessary  input  operations  of  converting  orders  to 
machine-readable  form,  mechanization  of  the  billing  and  accounting  functions, 
and  certain  other  data  handling  operations.  Phase  II  encompassed  the  output 
operations,  including  the  development  of  what  we  at  first  called  "Machine  X": 
a  machine  or  system  which  would  store  in  machine-readable  form  the  informa- 
tion now  printed  on  the  cards  in  stock  and  produce  printed  cards  from  this 
information  on  demand,  in  response  to  particular  orders.  The  interface 
between  Phase  I  and  Phase  II  would  be  a  daily  magnetic  tape  containing  order 
information  in  machine-readable  form,  which  would  tell  Phase  II  what  cards 
to  print,  in  what  quantities,  and  where  to  send  them.  It  was  obvious  that 
Phase  II  would  require  a  large-scale  development  effort  and  protracted  negotia- 
tions, and  work  on  it  was  therefore  begun  at  the  same  time  as  Phase  I. 

Since  Phase  I  would  be  implemented  first,  however,  it  was  desirable  that 
it  function  as  a  stand-alone  system  as  well  as  part  of  the  eventual  total 
system.  This  meant  two  general  requirements  for  the  Phase  I  system:  it  must 
economically,  reliably  and  speedily  convey  incoming  orders  to  machine- 
readable  form  for  further  processing,  and  it  must  provide  paper-handling 
capabilities  which  would  improve  the  manual  system  of  filling  orders  while  we 
were  waiting  for  Phase  II. 

In  addition  to  these  general  requirements,  however,  there  were  some 
unusual  system  constraints.  In  the  first  place,  the  orders  we  receive  are  unlike 
most  business  documents:  they  are  roughly  3"  x  5",  and  on  paper  rather  than 
cards.  The  information  is  recorded  in  a  multiplicity  of  typewriter  fonts  and,  in 
a  significant  number  of  cases,  in  handprinting.  More  importantly,  many 
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libraries  incorporate  a  card  order  slip  as  part  of  a  multi-part  form  used  to 
order  books;  this  meant  that  unless  we  were  to  require  libraries  to  change 
their  acquisitions  system  in  order  to  prepare  two  forms  instead  of  one,  the 
card  orders  would  have  to  remain  the  same  size  and  approximate  thickness 
and  be  capable  of  incorporation  into  a  multi-part  form. 

Secondly,  many  libraries  either  require  or  desire  that  the  original  order 
form  be  returned  to  them  with  the  catalog  cards  themselves;  some  use  a 
control  number  on  the  forms  to  match  the  cards  with  the  books  when  the 
cards  arrive,  and  others  have  a  legal  requirement  for  return  of  the  order.  It 
was  also  desirable  that  we  be  able  to  use  the  original  order  throughout  the 
order-filling  process,  since  it  contains  bibliographic  information  valuable  in 
searching  for  the  card  stock  number  or  in  verifying  the  accuracy  of  the 
order-filling  operation.  If  we  could  not  use  the  original  order  document 
throughout,  we  would  be  faced  with  the  prospect  of  converting  most  of  this 
information  to  machine-readable  form  in  order  to  reproduce  it  on  a  secondary 
stock  ticket  or  order-pulling  document,  and  we  would  still  have  to  match  the 
filled  orders  with  the  original  order  documents  before  mailing  them  to  the 
customer.  In  short,  we  wanted  to  use  an  order  form  as  much  like  the  old  one 
as  possible,  and  use  it  throughout  the  order-filling  process. 

A  great  many  systems  were  designed  on  paper,  but  most  of  the  obvious 
ones  were  discarded  because  of  these  two  constraints.  Keypunching  the  order 
information  (or  keyboarding  it  on  a  paper-tape  or  magnetic-tape  typewriter) 
and  then  generating  a  listing  of  what  cards  were  to  be  sent  to  whom  would 
have  required  keying  too  much  of  the  bibliographic  information,  the  high 
error  rate  involved  would  have  required  virtually  complete  verification,  and  at 
any  rate  there  was  little  prospect  (in  the  Washington  labor  market)  of  being 
able  to  hire  enough  keyboard  operators  to  do  the  job.  Fifty -one  column 
punched  cards  with  the  customer  number  prepunched  would  be  too  difficult 
to  incorporate  into  multi-part  forms.  Mark-sense  documents  require  too  much 
space  to  record  too  little  data.  Magnetic  ink  imprinted  documents,  such  as 
bank  checks,  turned  out  to  be  too  expensive  to  incorporate  in  multi-part 
forms,  and  so  forth. 

To  make  a  long  story  shorter,  it  became  increasingly  apparent  as  the 
analysis  proceeded  that  direct  optical  scanning  techniques  offered  the  most 
promising  possibilities  for  meeting  all  of  the  requirements,  and  our  investiga- 
tion of  such  equipment  was  therefore  intensified.  All  major  manufacturers  of 
optical  character-recognition  equipment  were  consulted,  and  several  submitted 
proposals.  Sample  forms  were  printed  and  tested,  and  the  National  Bureau  of 
Standards  and  the  General  Services  Administration  were  asked  to  help.  To 
shorten  the  story  again,  however,  the  Library  and  both  of  these  other  agencies 
agreed  in  the  end  that  only  one  manufacturer  combined  the  ability  to  read 
multiple  typewriter  fonts  and  hand-printing  with  the  high-speed  paper-handling 
capabilities  needed  for  this  application.  This  manufacturer  was  Recognition 
Equipment,  Inc.,  of  Dallas,  Texas,  otherwise  known  as  REI. 

With  this  much  established,  then,  we  began  a  detailed  study  of  how  a 
system  built  around  REI  equipment  might  function.  The  first  step  was  to  get 
more  information  about  the  orders  themselves  and  the  data  conversion  job 
involved.  Specifically,  we  needed  to  know  how  many  typewriter  fonts  libraries 
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were  using  on  order  forms  and  in  what  proportion.  A  sample  of  over  540,000 
order  slips  was  drawn  for  the  study,  and  with  REI's  help  the  typewriter  used 
to  produce  each  one  was  laboriously  identified.  The  results  are  reproduced  in 
Table  I.  Briefly  stated,  the  study  showed  that  handprinting  and  twenty-five 
commonly  used  typewriter  fonts  (listed  in  Table  II)  accounted  for  all  but  1 .8 
percent  of  the  sample.  Handprinting  appeared  on  almost  half  of  the  forms 
surveyed,  but  in  most  cases  only  the  card  number  was  printed,  presumably  by 
searchers  in  the  ordering  libraries  after  the  rest  of  the  information  had  been 
typed. 

Detailed  system  design  followed,  and  it  was  soon  clear  that  a  substantial 
increase  in  efficiency  and  some  reduction  in  costs  would  result  if  REI  could 
build  us  a  system  that  would  read  these  twenty-five  fonts  and  handprinting, 
quickly,  economically,  and  reliably;  that  would  convert  the  basic  information 
on  the  order  slip  to  machine-readable  form  and  use  it  to  produce  bills, 
monthly  statements,  accounting  documents  and  other  statistical  and  manage- 
ment reports;  and  that  would  arrange  the  order  slips  themselves,  once  read, 
into  sequences  that  would  improve  the  manual  order-filling  operation. 

They  could,  and  did.  In  May  1968,  purchase  orders  for  some 
twenty-two  pieces  of  equipment  were  issued;  in  August  1968,  the  equipment 
was  delivered;  in  September  1968,  installation  was  completed;  and  on  October 
2,  1968,  less  than  five  months  after  the  purchase  orders  were  issued,  the  first 
actual  catalog  card  orders  were  processed  through  the  system. 

The  way  the  system  works  is  illustrated  in  Figure  1 .  A  new  order  form 
(Figure  2)  places  the  information  to  be  converted— the  subscriber  number,  the 
type  of  handling  desired,  and  the  stock  number  of  the  card— in  a  single  band 
at  the  top  of  the  card.  The  subscriber  number  and  the  handling  code  are  pre- 
printed by  the  card  division  for  customers  using  single-part  forms,  and  by  the 
forms  supplier  for  customers  using  multi-part  forms.  The  card  stock  number  is 
typed  by  the  library,  or  (alternatively)  handprinted  in  specially-designed  boxes 
at  the  bottom  of  the  form.  Other  boxes  on  the  bottom  of  the  form  provide 
space  for  card  division  staff  to  indicate  special  handling  or  billing  procedures. 

Order  slips  are  placed  in  the  feed  of  the  OCR  device  as  they  arrive  from 
subscribers,  and  an  air-and-vacuum  transport  system  starts  them  through  the 
machine  at  a  constant  rate  of  1,200  documents  per  minute.  At  this  speed, 
they  become  a  dim  blur  to  the  human  eye,  but  the  machine  sees  them  and 
reads  them  in  a  fashion  directly  analogous  to  the  eye.  Light  is  bounced  off  the 
face  of  the  order  slip,  and  each  character  in  turn  is  reflected,  magnified  and 
projected  through  a  "light  tunnel"  onto  an  "electronic  retina."  The  "retina"  is 
composed  of  576  tiny  photo-cells  which  simulate  the  rods  and  cones  of  the 
human  retina.  A  single  wire  projects  from  the  back  of  each  cell,  like  a  nerve 
from  a  rod  or  cone  cell  in  the  eye,  and  light  striking  a  cell  generates  a  voltage 
along  this  wire  proportional  to  the  intensity  of  the  light.  These  wires  lead  to  a 
"recognition  unit,"  just  as  nerves  lead  to  the  visual  recognition  centers  of  the 
brain.  Note  that  up  to  this  point  the  system  is  functioning  as  an  analog 
computer,  not  a  digital  computer;  in  the  recognition  unit,  however,  the  vary- 
ing voltage  patterns  are  analyzed,  matched  against  hundreds  of  circuits 
representing  "known"  voltage  patterns,  a  "decision"  is  made  as  to  the  identity 
of  the  character,  and  the  digital  code  for  that  character  is  generated.  Actually, 
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thousands  of  electronic  analyses  are  made  of  each  character  before  a  final 
decision  on  its  identity  (or  lack  of  it)  is  made. 

The  recognition  unit  contains  about  150  circuits  (or  "masks,"  as  they 
are  called)  representing  the  characters  in  its  "vocabulary"  of  typewriter  fonts, 
and  almost  300  for  hand-printed  characters.  In  this  system,  only  numerals  are 
recognized,  because  letters  occur  only  infrequently  in  our  card  stock  numbers 
and  it  was  desirable  to  use  the  available  storage  space  to  recognize  as  many 
fonts  as  possible;  the  equipment  is  capable  of  recognizing  letters  and  other 
symbols,  however,  if  "masks"  for  them  are  ordered  as  part  of  the  "vocabu- 
lary." Only  150  masks  are  required  for  the  ten  digits  in  each  of  the 
twenty-five  fonts  (rather  than  250)  because  the  similarity  of  some  digits  in 
various  fonts  allows  the  system  to  recognize  that  digit  in  several  different 
fonts  with  only  one  mask;  many  more  circuits  are  required  for  handprinting, 
on  the  other  hand,  because  of  the  variety  of  ways  human  beings  make 
numerals. 

The  contract  with  REI  requires  the  equipment  to  read  the  "defined" 
typewritten  characters— that  is,  the  ten  digits  in  the  twenty-five  selected 
fonts— with  a  document  reject  rate  of  3  percent  or  less.  During  the  acceptance 
tests,  however,  it  rejected  (for  lack  of  recognition)  only  a  little  more  than  1 
percent  of  the  order  slips,  and  in  practice  we  find  that  the  reader  will  inter- 
pret many  other  fonts  besides  those  listed  in  Table  II,  including  proportional 
spacing  (the  twenty-five  listed,  however,  are  still  the  most  likely  to  be  read 
reliably).  We  had  also  anticipated  that  one  pass  would  have  to  be  made  for 
12-pitch  (elite)  type  and  one  for  10-pitch  (pica)  type,  because  of  the  different 

TABLE  II 

TYPEWRITER  FONTS 

Which  can  be  read  by  the  REI  Electronic  Retina  Computing  Reader 
used  in  the  Library  of  Congress  Automated  Catalog  Card  Distribution  System 

Elite  (12  Pitch)  Pica  (10  Pitch) 

IBM  Cloister  Elite  IBM  Large  Pica 

IBM  Prestige  Elite  IBM  Prestige  Pica 

IBM  Scribe  IBM  Standard  Manifold  Pica 

IBM  Standard  Elite  R.  C .  Allen  Pica 

R.  C.  Allen  Elite  Remington  Pica 

Remington  Elite  Royal  Contemporary  Pica 

Remington  New  Royal  Standard  Pica 

Royal  Canterbury  Royal  Windsor  Pica 

Royal  Contemporary  Smith  Corona  Standard  Pica 

Royal  Oxford  Underwood  Distinctive  Pica 

Royal  Standard  Elite 

Smith  Corona  Elite  Modified  Other 

Smith  Corona  Elite  Regular 

Underwood  Distinctive  Elite  1403  Line  Printer 
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timing  required  to  locate  each  successive  character;  in  practice,  however,  we 
read  both  12-pitch  and  10-pitch  characters  in  the  same  pass. 

Once  the  recognition  unit  identifies  a  character,  the  information  is  con- 
verted from  analog  to  digital  form  and  transmitted  to  one  of  three  small-scale 
computers  and  from  there  to  a  small  but  complex  device  called  an  ink-jet 
printer.  This  unit  is  installed  on  the  document  transport  about  half-way  along 
the  path  traveled  by  each  order  slip  and  resembles  a  small  hypodermic  needle. 
It  oscillates  at  about  48,000  oscillations  per  second,  breaking  up  a  stream  of 
fluorescent  red  ink  into  tiny  droplets,  and  spraying  tiny  bars  on  the  back  of 
each  order  slip  as  it  passes  by.  The  bars  are  printed  in  an  octal  code  represent- 
ing the  information  read  from  the  front  of  the  order  slip,  and  will  be  used  in 
the  sorting  process  later  on. 

The  computer  also  transmits  the  order  information  to  an  1,100 
line-per-minute  drum  printer,  which  prints  out  the  information  to  initiate  an 
audit  trail  (the  same  printer  is  used  for  pre-printing  the  subscriber  numbers  on 
the  order  slips). 

Depending  on  what  information  is  read  or  not  read  from  the  front  of 
the  order  slips,  they  fall  finally  into  one  of  several  pockets.  Those  which  have 
been  read  and  sprayed  are  sent  on  to  the  sorters,  as  described  below;  those 
without  a  card  number  are  sent  to  the  searchers  to  have  the  number  looked 
up  (and  handprinted  in  the  boxes  on  the  bottom  of  the  slip);  those  which 
were  rejected  are  passed  through  the  reader  a  second  and  (if  necessary)  a  third 
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time,  and  most  of  them  are  then  read  and  sprayed;  those  which  still  cannot  be 
read  and  those  which  contain  other  errors  (strikeovers,  incomplete  erasures, 
or  erroneous  numbers  on  which  the  check  digit  arithmetic  does  not  work)  are 
sent  to  staff  members  who  imprint  the  information  on  the  back  of  the  slip 
and  return  it  to  be  read  with  the  next  batch. 

Sooner  or  later,  then,  all  slips  are  read  and  sprayed  with  fluorescent  bar 
coding  on  the  back.  The  slips  are  then  placed  in  one  of  four  large  sorting 
machines,  called  bar-code  reader-sorters.  These  devices  have  a  transport  system 
similar  to  the  character  reader,  and  thirteen  pockets,  just  like  an  IBM 
punched-card  sorter.  The  sorting  logic  is  the  same  as  an  IBM  sorter,  the 
difference  being  that  these  machines  read  bar  codes  instead  of  punched  holes. 
They  also  handle  paper  documents  as  well  as  cards,  and  can  handle  documents 
of  intermixed  sizes  and  thicknesses;  like  the  character  reader,  they  operate  at 
a  constant  rate  of  1,200  documents  per  minute. 

On  these  machines,  the  slips  are  first  sorted  into  sequence  by  card  stock 
number.  The  information  from  each  order  is  then  written  on  a  daily  trans- 
action tape  which  is  used  for  billing  and  accounting  purposes  and  is  also 
cumulated  at  weekly  and  monthly  intervals  for  statistical  and  management 
information  purposes  (most  importantly,  the  cumulative  information  on 
ordering  activity  indicates  how  much  stock  should  be  reprinted  for  particular 
titles,  in  order  to  reduce  the  out-of-stock  rate).  At  the  same  time,  the  slips  are 
compared  with  another  magnetic  tape  listing  of  those  card  numbers  known  to 
be  out  of  stock;  orders  for  these  cards  are  sorted  out  to  be  sent  directly  to  the 
reprint  unit  and  await  the  printing  of  new  stock,  thus  bypassing  the  main 
order  filling  unit  and  effectively  reducing  the  workload  of  that  unit  by  about 
25  or  30  percent. 

The  main  purpose  of  sorting  the  slips  into  numerical  sequence,  however, 
is  to  improve  the  efficiency  of  order  filling  in  another  way.  Now  that  all 
orders  for  the  same  title  are  together,  they  can  be  filled  at  the  same  time,  and 
all  orders  to  be  filled  from  one  drawer  can  be  filled  with  one  opening  of  the 
drawer;  this  technique  alone  has  so  far  increased  productivity  in  order  filling 
by  over  60  percent. 

As  the  orders  are  filled,  the  order  fillers  place  the  required  catalog  cards 
behind  each  order  slip.  The  intermixed  order  slips  and  catalog  cards  are  then 
returned  to  the  sorting  machines  and  sorted  into  sequence  by  subscriber 
number,  so  that  all  of  the  slips  and  cards  to  be  mailed  to  a  particular  sub- 
scriber are  brought  together,  ready  for  mailing.  Modification  of  the  sorting 
equipment  to  enable  it  to  handle  intermixed  order  slips  and  cards  was  one  of 
the  main  technical  accomplishments  of  the  project.  Once  the  orders  are  thus 
arranged  for  mailing,  address  labels  and  invoices  for  each  shipment  are  printed 
out  on  the  line  printer  and  the  orders  are  wrapped  and  shipped. 

A  general  flow  chart  of  the  Phase  I  system  is  reproduced  as  Figure  3. 
Each  numbered  block  in  this  diagram  summarizes  a  set  of  flow  charts  for 
major  subsystems  (or  major  manual  operations),  and  some  of  these  deserve 
further  mention.  Block  8  represents  the  inventory  control  subsystem,  which 
includes  not  only  passing  the  order  slips  against  the  magnetic  tape  listing  of 
cards  known  to  be  out  of  stock,  (as  indicated  in  Block  4),  but  also  procedures 
for  adding  new  numbers  to  the  out-of-stock  tape  (or  deleting  them,  in  the 
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Figure  3  -  Flowchart  of  Phase  I  System 
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case  of  newly-printed  stock),  procedures  for  creating  documents  which  initiate 
the  reprinting  cycle,  and  procedures  which  produce  printed  registers  of  titles 
in  the  reprinting  cycle  by  card  number  and  by  subscriber  number. 

Block  7  indicates  the  order  control  subsystem,  which  provides  an 
automatic  means  of  insuring  that  all  orders  received  at  the  beginning  of  the 
system  are  accounted  for,  and  that  subscribers  are  not  billed  erroneously. 
Block  9  represents  the  accounting  control  subsystem,  which  not  only  creates 
the  invoices  packed  with  each  shipment  but  also  produces  the  monthly  state- 
ments and  a  variety  of  other  necessary  fiscal  documents.  Not  shown  on  the 
chart  but  also  important  are  other  programs  and  procedures  for  producing 
statistical  analyses  and  management  reports  which  help  control  and  regulate 
the  entire  operation. 

This  then  is  the  Phase  I  system  now  in  operation.  So  far  it  has  enabled 
us  to  eliminate  the  manual  billing  operation,  to  mechanize  much  of  our 
accounting  work,  to  increase  productivity  in  the  key  activity  of  order-filling 
by  about  100  percent,  to  gain  better  inventory  control,  to  obtain  valuable 
statistical  and  analytical  information  not  available  before,  and,  most  im- 
portantly, to  reduce  the  time  required  to  fill  a  regular  order  (provided  cards 
are  in  stock)  from  three  to  four  weeks  to  seven  days.  That  is  to  say,  orders 
received  on  the  new  order  forms  for  which  cards  are  in  stock  are  now  shipped 
within  seven  calendar  days,  rather  than  in  three  or  four  weeks  as  before. 

You  will  notice  that  the  improved  performance  results  only  if  cards  are 
in  stock;  if  cards  are  out  of  stock,  a  delay  still  results  because  of  the  time 
required  to  print  more  stock.  The  Phase  I  system  helps  control  the  process, 
but  the  real  solution  to  this  problem  lies  in  eliminating  the  process  altogether 
by  printing  cards  only  on  demand,  automatically,  from  a  machine-readable 
store.  This  is  the  function  of  Phase  II,  as  indicated  earlier. 

Because  of  the  development  effort  required  in  Phase  II,  a  Request  for 
Proposals  (RFP)  was  issued  in  October  1967  to  over  100  firms;  the  specifica- 
tions in  the  RFP  called  for  a  system  capable  of  storing  the  information  on  six 
million  catalog  cards,  retrieving  this  information  on  demand  for  up  to  100,000 
orders  per  day,  and  reproducing  up  to  600,000  cards  per  day  to  fill  these 
orders.  The  specifications  also  called  for  reproduction  in  type  fonts  similar  to 
those  presently  used  on  cards,  including  non-Roman  alphabets  and  other 
characters  now  used  to  print  cards  in  some  125  languages,  and  they  required 
reproduction  on  paper  of  archival  quality,  at  close  tolerances,  and  with  a 
minimum  resolution  of  4.5  line  pairs  per  millimeter  (about  254  lines  per 
inch). 

Eight  proposals  were  received  in  January  1968,  and  were  extensively 
analyzed  by  a  Technical  Proposal  Evaluation  Group.  In  March  1968,  cost  bids 
were  requested  on  three  of  the  proposed  systems,  and  after  evaluating  the 
technical  merits  of  the  competing  proposals  as  compared  with  their  cost,  the 
Library  determined  in  May  1968,  that  the  system  proposed  by  RCA  was  the 
most  advantageous.  In  April  1969,  the  Library  received  formal  permission 
from  the  Joint  Committee  on  Printing  to  proceed  with  acquisition  of  the 
system,  and  we  hope  to  have  .it  operating  early  next  year. 

Figure  4  illustrates  the  way  in  which  the  total  system  will  operate  once 
Phase  II  is  implemented;  Phase  I,  as  it  will  function  in  the  total  system  rather 
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than  as  a  stand-alone  system,  is  represented  in  the  top  and  leftmost  segments 
of  the  diagram,  and  Phase  II  is  in  the  right  and  bottom  segments.  Some 
sorting  of  the  actual  order  slips  will  still  be  necessary  to  arrange  them  by 
subscriber  number  for  return  to  the  individual  subscribers,  but  sorting  the  slips 
by  card  number  and  sorting  the  catalog  cards  will  no  longer  be  necessary. 
Instead,  the  magnetic  tape  containing  the  order  information  in 
machine-readable  form  will  be  read  by  a  Spectra  70/45  computer,  which  will 
then  retrieve  from  mass  storage  units  the  digitized  catalog  records  needed  to 
fill  that  day's  orders.  The  computer  will  then  obtain  from  magnetic  disk 
storage  the  digitized  images  of  each  character  needed  for  these  particular 
cards,  and  assemble  the  records  with  the  digitized  images  of  each  needed 
character  on  another  magnetic  tape.  This  magnetic  tape  will  in  turn  be  read 
by  one  of  two  RCA  Videocomp  Model  830  photocomposition  machines,  each 
of  which  contains  its  own  computer  and  memory  as  well  as  a  cathode  ray 
tube  imaging  device  and  a  sophisticated  optical  system.  The  Videocomps  will 
compose  continuous  photographic  masters  (see  Figure  5)  each  containing  ten 
card  images,  in  appearance  almost  identical  to  the  cards  now  printed  by  letter- 
press and  more  conventional  methods;  composition  will  be  done  at  several 
thousand  characters  per  second,  and  at  a  very  high  resolution  (450  lines  per 
inch). 

From  this  point,  the  succeeding  steps  take  place  in  assembly-line 
fashion.  The  masters  are  developed  by  a  continuous  plate  processor,  cut  into 
individual  ten-up  masters,  and  dropped  into  the  feed  trays  of  automatic  offset 
presses.  These  presses  automatically  load  the  masters  in  turn,  revolve  the 
number  of  times  required  to  produce  the  correct  number  of  copies  of 
particular  cards,  automatically  eject  each  master,  go  through  a  cleaning  cycle, 
and  then  load  the  next  master.  In  the  meantime,  the  printed  sheets  of  cards 
travel  to  another  station  on  the  line  (see  Figure  6),  where  they  are  cut  by 
rotary  knives  into  separate  cards,  and  then  stacked,  with  each  customer's 
order  in  a  separate  stack  and  an  address  card  on  top.  The  cards  then  pass 
through  a  shrink-wrap  packaging  station,  which  wraps  each  order  with  a  thick 
polyethylene  film,  seals  the  package,  and  then  drops  it  into  the  mail  bag.  You 
will  see  by  this  description  and  the  chart  that  with  full  implementation  we 
will  have  achieved  the  goal  of  automating  the  entire  process,  from  the  receipt 
of  the  order  in  the  incoming  mail  to  the  shipment  of  the  order  in  the  out- 
going mail. 

As  I  indicated  earlier,  the  initial  implementation  of  this  part  of  the 
system  will  be  completed  some  time  in  1970.  Full  implementation  will  require 
conversion  of  the  catalog  cards  now  in  stock  to  machine-readable  form,  but 
the  data  base  available  from  the  MARC  project  will  enable  us  to  make  fairly 
full  utilization  of  the  initial  system,  since  the  MARC  records  are  for  current 
English-language  materials  and  it  is  these  cards  which  are  most  in  demand. 
Those  orders  which  cannot  be  handled  by  the  Phase  II  system  will  be  handled 
by  the  Phase  I  system  described  above,  but  as  the  conversion  effort  proceeds 
(perhaps  in  conjunction  with  other  conversion  efforts)  the  volume  processed 
through  the  full  system  will  rise  rapidly,  even  though  it  may  be  several  years 
before  all  orders  are  handled  in  this  way. 
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Figure  5  —  Photographic  Masters  of  Card  Image 
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When  Phase  II  has  been  implemented,  the  space  required  to  maintain 
large  stocks  of  printed  cards  will  be  eliminated,  the  time  required  to  fill  orders 
will  be  reduced  still  further  (particularly  for  those  which  now  enter  the  reprinting 
cycle),  and  hopefully  the  cost  of  the  cards  will  be  reduced.  At  that  time,  in 
short,  we  will  be  much  closer  to  our  goal  of  providing  the  best  catalog  card 
service  possible  to  meet  the  needs  and  demands  of  the  nation's  libraries. 


James  B.  Cor  bin 

Assistant  Librarian  for  Systems  Analysis  and  Technical  Processing 

Tarrant  County  Junior  College  District 
Fort  Worth,  Texas 


THE  DISTRICT  AND  ITS  LIBRARIES— 

TARRANT  COUNTY  JUNIOR  COLLEGE  DISTRICT 

FORT  WORTH,  TEXAS 

Tarrant  County  in  north-central  Texas  has  860  square  miles,  a  popula- 
tion of  approximately  700,000,  and  contains  the  metropolitan  area  of  Fort 
Worth.  Its  junior  college  district— formed  in  1965  and  supported  by  county  ad 
valorem  taxes  and  general  obligation  bonds  and  supplemented  by  state  and 
federal  funds— will  ultimately  include  four  or  five  campuses  located  in  widely 
separated  sectors  of  the  county. 

While  the  district  offices  in  Forth  Worth  will  house  the  quarters  of  the 
president  and  central  services  such  as  personnel,  business  affairs,  planning  and 
development,  public  relations,  and  so  on,  each  separate  campus  will  have  its 
own  executive  dean,  faculty,  and  curriculum.  The  curricula  emphasis  will  be 
split  between  terminal  vocational  courses  and  college  and  university  parallel 
courses. 

Each  campus  will  also  have  its  own  library,  with  a  head  librarian  and 
staff  and  a  complete  collection  of  materials  reflecting  the  curriculum  of  each 
campus.  A  director  of  library  services  will  coordinate  the  library  activities  on 
all  the  campuses. 

The  first  campus  opened  in  September  1967,  and  the  second  in  January 
1969.  The  third  campus  will  open  in  1973,  and  the  remaining  ones  in  the 
middle  or  late  1970's.  The  eventual  district  enrollment  is  envisioned  to  be 
over  20,000,  while  the  two  existing  campuses  now  have  around  8,000 
students. 
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OBJECTIVES  OF  THE  AUTOMATION  PROGRAM 

A  prime  objective  of  the  automation  program  of  the  libraries  of  the 
district  is  for  the  system  to  provide  maximum  and  superior  library  services  to 
its  students,  faculties,  and  staffs  with  a  minimum  of  library  personnel. 

In  realizing  this  objective,  some  specific  goals  are  to  provide  each  library 
with  materials  acquired  and  processed  rapidly,  efficiently,  and  inexpensively; 
to  provide  each  staff  with  reports  and  analyses  of  their  services  in  order  that 
those  services  might  be  interpreted  properly,  refined,  and  improved;  to  reduce 
for  each  staff  member  the  burden  of  performing  many  routine  and  mundane 
tasks  in  order  that  they  devote  more  of  their  time  to  working  with  the 
students  and  faculty;  and  to  remove  from  the  students,  faculty,  and  staff  as 
many  barriers  as  possible  to  their  intelligent,  rapid,  and  pleasant  use  of  each 
library. 

The  emphasis  in  the  program  is,  as  it  should  be,  on  the  services  per- 
formed and  on  those  persons  performing  the  services,  not  on  the  devices  or 
techniques  used.  But  the  machines  and  machine  methods  are  not  subjugated 
or  de-emphasized  completely,  for  our  services  are  based  on  staff  and  machines. 

ORGANIZATION  OF  THE  AUTOMATION  SERVICES 

While  each  campus  of  the  district  has  its  own  separate  library  and 
individual  staff,  the  services  provided  by  the  automation  program  are  the  same 
for  all.  To  conserve  time,  energy,  space,  and  money,  the  ordering,  receiving, 
cataloging,  and  further  processing  of  all  district  library  materials  are  handled 
in  one  location  and  by  one  staff. 

The  planning,  coordinating,  and  implementing  of  all  automation 
activities  are  vested  in  an  assistant  librarian  for  systems  analysis  who  works 
closely  with  the  director  of  libraries,  each  library  staff,  and  the  computer 
center  personnel.  All  computer  programming  is  done  by  the  programmers  in  a 
central  computer  center. 

THE  EQUIPMENT  USED 

The  system  was  developed  initially  and  has  operated  for  over  a  year  on 
an  IBM  1401  computer  using  two  tape  and  two  disk  drives  which  is  located  in 
the  central  computer  center  which  serves  the  entire  district. 

For  the  past  six  months,  work  has  been  in  progress  to  convert  all  the 
libraries'  1401  programs  to  those  for  a  third  generation  RCA  Spectra  70, 
Model  35  (65K),  with  four  tape  drives  and  two  disk  drives.  Autocoder  lan- 
guage was  used  for  all  1401  programs,  and  the  assembly  and  COBOL  languages 
are  used  for  the  Spectra  programs. 

While  the  main  reason  for  the  conversion  is  that  the  district  intends  to 
do  away  with  the  second-generation  IBM  1401  entirely,  the  occasion  had 
provided  a  means  of  incorporating  new  ideas  into  the  programs,  of  expanding 
the  system,  and  deleting  many  of  the  mistakes  and  blunders  made  when  we 
were  groping  our  way  with  untried  ideas  and  lack  of  guidelines. 

At  the  present  time,  only  the  circulation  activities  have  been  repro- 
grammed,  tested,  and  converted  completely  to  an  operational  status  on  the 
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Spectra  70.  The  remainder  of  the  system  is  in  various  stages  of  reprogram- 
ming,  all  due  to  be  completed  by  the  end  of  summer  1969.  However,  all  1401 
programs  will  be  operated  until  the  complete  change-over  is  made.  The  pro- 
gram described  in  this  paper  will  be  a  combination  of  systems  in  operation  for 
the  past  two  years  and  of  planned  changes  for  the  larger  computer.  All  opera- 
tions are  presently  "off-line"  from  the  computer,  on  a  batched  process  mode 
having  a  week  as  the  main  cycle  time. 

DEFINITION  AND  DESCRIPTION  OF  THE  "TOTAL  SYSTEM" 

That  elusive,  ill-defined,  and  poorly  understood  "total  system"  or  inte- 
grated system  concept  is  the  basis  for  the  automation  program  of  the  libraries 
of  the  Tarrant  County  Junior  College  District.  From  the  machine-readable 
records  prepared  as  each  bibliographic  item  is  entered  into  our  system  origi- 
nate, either  directly  or  indirectly,  a  full  range  of  machine  routines  and  reports 
that  provide  services  throughout  the  libraries'  organizational  structures.  In 
most  cases,  output  from  one  subsystem  is  mandatory  input  into  the  next 
subsystem  and  so  on  from  program  to  program. 

Very  simply,  our  system  is  based  on  a  magnetic  tape  file  of  records 
containing  bibliographic,  ordering,  and  other  inventory  information  with 
controlling,  excerpting,  modifying,  and  monitoring  systems  inserted  at  set  and 
necessary  intervals  of  time  to  tap  this  file  to  provide  us  with  the  services  and 
reports  we  desire  and  need. 

While  most  of  the  machine  services  require  the  use  and  re-use  of  the 
same  information  stored  on  the  tapes,  several  services  depend  upon  the  tape 
files  originally,  but  afterwards  are  completely  independent.  For  example,  once 
enough  information  from  the  tape  records  is  excerpted  to  prepare  the 
machine-readable  book  master  or  circulation  cards,  the  circulation  activities 
become  a  totally  independent  subsystem  of  the  main  system.  Figure  1 
indicates  the  five  major  subsystems  of  the  system  which  comprise  our  present 
program. 

THE  MASTER  TAPE  RECORDS 
The  Source  Document 

The  source  document,  called  the  library  order  card,  used  by  the  libraries 
as  input  into  the  automated  system  is  a  multi-functional  one:  1)  it  is  a  request 
form  for  the  faculty  and  library  staff;  2)  it  is  a  form  for  verifying,  searching, 
and  coding  of  bibliographic,  order,  and  other  information  that  will  become  a 
part  of  the  master  record;  3)  it  is  the  source  document  for  keypunching;  and 
4)  it  is  a  back-up  record  in  case  the  punched  cards  or  magnetic  tape  are  lost 
or  destroyed. 

Information  on  each  library  order  card,  which  is  5"  x  8"  in  size,  is 
verified  and  searched  in  the  traditional  manner  by  locating  the  record  in  the 
Library  of  Congress  proof  sheet  file,  in  the  National  Union  Catalog,  Publishers' 
Weekly,  or  so  on.  Information  on  the  order  card  is  added  to,  changed, 
deleted,  or  coded  into  the  required  format  before  the  forms  are  sent  in 
weekly  batches  to  the  keypuncher.  Figure  2  illustrates  a  completed  library 
order  card  ready  to  be  sent  to  the  keypuncher. 
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ORDERING 

.Duplicate 

Record 

Searches 
.Purchase 

Orders 
."On  Order" 

Lists 
.Follow-Up 

Orders 


PREPARATION 
OF  MATERIALS 

.Spine  Labels 
.Pocket 

Labels 
.Book  Master 

Cards 


ACCOUNTING 

•Budget 

Reports 
. Inventory 

Lists 
.Analyses  of 

Orders 


MASTER  TAPE  RECORDS 


CIRCULATION 

.Borrower  Regis- 
tration 

.Daily  Circula- 
tion Lists 

•Daily  Reserve 
Lists 

•Circulation 
Statistics 

•Overdue  Notices 

.Analyses  of 
Circulation 
Activitie  s 

•Fine  Notices 


INDEXING 

.  Author 

Catalogs 
•Title 

Catalogs 
.Subject 

Catalogs 
.Special 

Lists 


Figure   1  --  The  Five  Major  Service  or  Report  Areas  of  the  System 
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The  Punched  Input  Cards 

Information  on  the  order  cards  is  punched  into  cards  and  the  punching 
is  verified.  The  function  of  these  punched  cards,  which  are  of  a  fixed  format 
with  twelve  cards  per  set  for  each  record,  is  to  provide  a  means  by  which 
information  on  the  order  cards  can  be  transferred  to  magnetic  tape  or  disk. 
Figure  3  is  of  a  set  of  punched  input  cards  for  a  bibliographic  record.  Once  a 
week,  the  punched  input  cards  for  new  records  are  read  into  storage.  While 
magnetic  tape  is  the  permanent  medium  used  to  store  the  records,  the  disk 
packs  are  used  for  processing  the  records. 

Pre-Processing  the  Records 

As  information  punched  in  the  input  cards  is  read  into  storage,  certain 
defined  error  conditions  detected  will  cause  the  records  in  question  to  be 
printed  on  an  error  listing,  along  with  the  reasons  for  rejecting  the  records. 
While  the  verification  step  in  the  punching  stages  catches  most  obvious  errors, 
the  input  error  routine  detects  many  unobvious  errors,  such  as  the  absence  of 
the  maximum  or  minimum  number  of  characters  in  particular  fields,  or  the 
presence  or  absence  of  alpha  or  numeric  information  in  other  fields. 

After  the  error  listing  is  returned  to  the  library,  the  library  order  cards 
with  detected  errors  are  pulled,  the  errors  are  corrected,  and  the  cards  are 
placed  in  the  next  cycle.  Figure  4  is  of  a  sample  input  error-listing. 

The  Duplicate  and  Cancelled  Record  Check 

After  the  new  records  are  in  storage,  the  next  phase  of  the  program  is 
to  check  for  duplicate  and  cancelled  records.  The  function  of  this  search  is  to 
determine  if  any  new  records  being  processed  duplicate  any  records  already  in 
permanent  storage.  In  addition,  this  check  determines  if  any  new  records 
match  any  records  already  in  storage  which  previously  have  been  ordered  and 
subsequently  cancelled  by  vendors.  The  main  field  of  comparison  for  these 
checks  is  that  of  the  LC  classification  number. 

Both  duplicate  and  cancelled  records  are  reported  to  the  library  by 
printing  them  on  a  list  and  by  punching  a  card  for  each  item  located.  The 
listing  provides  enough  information  to  enable  the  library  staff  to  locate  the 
records  in  question  and  to  make  decisions  concerning  their  further  disposition. 
A  pending  status  code  is  appended  to  each  new  record  whose  future  is 
questionable. 

If  it  is  then  desirable  that  an  item  be  ordered  regardless  of  its  duplica- 
tion of  another  already  on  the  tape  or  regardless  of  the  fact  that  an  item  had 
been  previously  ordered  and  subsequently  cancelled  by  a  vendor,  then  the 
punched  card  is  marked  with  an  "0"  for  "order."  If  no  duplicate  item  is 
wanted  or  if  it  is  felt  that  it  would  be  a  waste  of  time  to  re-order  an  item 
previously  cancelled,  then  the  punched  card  is  marked  with  a  "D"  for  "de- 
lete." These  punched  cards  are  sent  back  to  the  computer  center  for  further 
processing  in  the  next  weekly  cycle.  Items  to  be  ordered  regardless  of  duplica- 
tion are  included  in  the  next  group  of  purchase  orders  printed,  while  those  to 
be  deleted  simply  are  dropped  permanently  from  the  files. 
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TARRANT  COUNTY  JUNIOR  COLLEGE  DISTRICT 
LIBRARY  ACQUISITIONS  INPUT  CARD  ERROR  LISTING 

APRIL      16*  1969 


032019999  0101-H 


CARD 


INVALID  CAMPUS  CHOP 


102019999  0101*1        BLANK  IN  COPIES 

REF/INDFX  INVALID 
INVALID  CAMPUS  CODE 

MEDIA  IS  PLANK 
ALPHA  IN  MFOIA 
NO  VENDHR  C01E 
ALPHA  IN  VENDOR  CODE 


03   Z  606UUV990  0101'M 

031?  1&]   9999  010101 

'0312  f>6lA19999  0101"! 

•0312  06101      0101"! 

5/OUI  06101A999  010101 

S031?  061019  99  010101 


90312    0610199991010101 


BLANK  IN  VENDOR  CODE 
INVALID  *Y»ASS  CODE 
INVALID  BYPASS  CODE 


POI12    02101002?  0101-11  TEST* 

90112    0210100^3  PlOloj.  TESTS 

OAPC. 1234. ABC     0  OR  n  IS  NOT  IN  COLUMN  77 

1ABC. 1234. ABC     0  OR  0  IS  NOT  IN  COLUMN  77 
2ARC.1?34.AI}C      P  OR  "  IS  NOT  IN  COLUMN  77 


ERROR 

ITEMS  FIELD  NOT  ACCURATE 

12L          CAMPUS  FIELD  NOT  0-4 

FUND  MISSING  FROM  TABLE 
ITEMS  FIELD  NOT  ACCURATE 

12L          COPIES  FIFLP  CONTAINS  BLANI 
FUND  MISSING  FROM  TABLE 
ITEMS  FIELD  NOT  ACCURATE 

1?L          REF. /INDEX  FIELD  INVALID 
FUND  MISSING  FROM  TABLE 

12L          CAMPUS  FIELD  NQT  0-4 

FUND  MISSING  FROM  TABLE 
ITEMS  FIELD  NOT  ACCURATE 

12L         MEDIA  FIELD  CONTAINS  BLANK 
FUND  MISSING  FROM  TABLE 

12L          MEDIA  MISSING  FROM  TABLF 
FUND  MISSING  FROM  TABLE 

12L          VENDOR  FIELD  MISSING 

FUND  MISSING  FROM  TABLE 

12L          COPIES  FIELD  NOT  NUMERIC 
CAMPUS  FIELO  NOT  NUMERIC 
VENDOR  FIELD  CONTAINS  BLAN! 
FUND  MISSING  FROM  TABLE 
ITEMS  FIELD  NOT  ACCURATE 

12L         VENDOR  FIELD  CONTAINS  BLAN 
FUND  MISSING  FROM  TABLE 

121          BYPASS  CODE  INVALID 

FUND  MISSING  FROM  TABLE 

1?L         BYPASS  CODE  INVALID 

FUND  MISSING  FROM  TABLE 

12L          FUND  MISSING  FROM  TABLE 

12U          FUND  MISSING  FROM  TABLE 
13L         INVALID  CODE  COLUMN  77  -  D 

915L         INVALID  COOF.  COLUMN  77  -  Dl 
A15L          INVALID  COOF  COLUMN  77  -  D 


Figure  4  —  A  Sample  Input  Error-listing 


If  it  is  known  in  advance  that  a  new  record  will  be  a  duplicate  of  one 
already  in  the  file,  a  special  by-pass  code  can  be  added  to  the  new  record 
before  keypunching,  and  the  duplicate  or  cancelled  record  search  will  not  be 
made  for  that  record.  This  will  allow  added  copies  or  volumes  to  be  added 
with  no  delay. 

Record  Maintenance 

Often  records  must  be  deleted  from  the  permanent  tape  files,  informa- 
tion in  fields  of  records  must  be  deleted,  added  to,  altered,  or  the  status  of 
records  must  be  changed  for  special  reasons.  As  new  material  is  received  from 
vendors,  each  item  in  hand  is  compared  with  its  tape  record  of  previously- 
captured  information,  via  the  "on  order"  list.  Some  common  causes  for 
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changes  in  the  pre-cataloged  tape  records  are  the  receipt  of  items  with  variant 
publishers'  names,  new  editions,  different  dates  of  publication,  and  even 
simple  keypunching  errors  not  caught  previously.  When  items  are  cancelled  by 
vendors  as  being  out  of  print,  permanently  out  of  stock,  and  for  several  other 
reasons,  then  their  status  must  be  changed  from  "on  order"  to  "cancelled"  on 
the  tape. 

When  any  of  these  conditions  arises,  a  maintenance  form  is  completed 
by  the  library  staff  indicating  the  accession  number  of  the  record  and  the 
information  to  be  changed,  added,  or  deleted.  This  information  then  is 
punched  into  cards  and  run  through  a  maintenance  program  to  up-date  the 
master  records  accordingly.  An  image  listing  of  each  record  before  and  after 
changes  is  sent  to  the  library  for  its  benefit. 

As  each  week's  new  records  are  read  into  storage  and  merged  onto  the 
master  tape,  a  list  is  printed  to  inform  the  library  staff  of  any  missing  ac- 
cession numbers  in  the  sequence,  or  of  any  new  accession  numbers  duplicating 
any  assigned  to  other  records  already  stored  on  the  tape.  Once  a  year  before 
the  annual  cumulative  book  catalogs  are  printed,  all  records  with  a  "can- 
celled" status  are  deleted  from  the  tape  file..  A  listing  of  these  items  allows 
the  library  staff  to  consult  it  if  needed  when  ordering  new  items. 

Other  Basic  Records 

There  are  two  other  types  of  records  besides  the  basic  bibliographic 
records  which  can  be  stored  on  the  tapes;  both  are  worth  mentioning  briefly. 
A  supplementary  serial  record  provides  a  means  by  which  the  basic  record  for 
serial-type  items  such  as  periodicals,  annuals,  proceedings,  etc.,  can  be  supple- 
mented with  a  detailed  listing  of  any  or  all  individual  volumes,  issues,  parts, 
and  so  on,  comprising  these  records. 

These  supplementary  records  simply  are  appended  to  their  main  records 
by  means  of  adding  sub-accession  numbers  to  the  basic  records'  accession 
numbers.  Thus,  when  individual  volumes  or  parts  must  be  added  to  records, 
this  can  be  done  without  altering  the  basic  bibliographic  records  or  without 
adding  completely  new  and  duplicate  records.  In  this  manner,  a  library's  hold- 
ings of  serial-type  items  can  be  reflected  completely,  uniquely,  and  easily. 

The  other  type  of  record  is  for  cross  references,  which  provides  a  means 
by  which  the  users  of  the  book  catalogs  can  be  referred  from  headings  or 
entries  in  the  listings  to  others.  Only  author  and  subject  heading  cross  refer- 
ences can  be  used,  but  both  "see"  and  "see  also"  references  can  be  inserted. 

The  basic  library  order  card  itself  is  used  as  a  source  document  for  cross 
references,  with  only  the  appropriate  cross  references  recorded,  plus  dummy 
accession  and  LC  numbers  and  several  other  special  codes  necessary  to  the 
program. 

SERVICES  AND  REPORTS  GENERATED 
FROM  THE  MASTER  TAPE  RECORDS 

The  new  records  placed  in  the  files  now  are  ready  to  be  processed. 
Keypunching  and  verifying  each  weekly  cycle's  batch  begins  on  Monday  and 
usually  takes  four  days.  Loading  the  new  records  into  storage,  checking  for 
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duplicate  and  cancelled  records,  and  printing  all  error  and  other  listings 
usually  takes  only  a  few  minutes,  beginning  on  the  Monday  after  library  order 
cards  are  sent  to  the  keypuncher  initially. 

The  Purchase  Orders 

The  new  records  are  sorted  first  by  vendor  code  number,  then  by 
publisher,  then  by  author,  and  then  by  title  under  author.  Purchase  orders  are 
printed,  with  all  items  having  the  same  vendor  number  being  placed  on  the 
same  order.  An  "on  order"  status  code  and  the  date  of  the  printing  are 
appended  to  each  new  record  included  on  a  purchase  order.  Figure  5  shows  a 
purchase  order  ready  to  be  mailed  to  the  vendor. 

TARRANT  COUNTY  JUNIOR  COLLEGE  DISTRICT         OWGDWU- 


BAKER  ANC  TAYLOR 
NOMENCE,  ILLINOIS  60954 


NOVEMBER    25,  1968 

SHIP  AIL  MATERIALS,  1  INVOICE  TO; 


LEARNING  RESOURCES  CENTER 
TARRANT  COUNTY  JUNIOR  COLLEGE 
5301  CAMPUS  DRIVE 
FORT  WORTH.  TEXAS    76 119 


DESCRIPTION 


EACH       EXTENSION 


BROOKtNGS  INST        -  SUNOOU.IST,  JAMES  L 
POLHICS  ANC  POLICY,  THE  EISENHOWER. 


BURGESS  PUB 


-  THOMPSON,  DAVID  WILLIAM 


ORAL  INTERPRETATION  OF  FICTION,  A  0.   2ND  ED.   1967. 


FUNK  -  THIBAUDET,  ALBERT 

FRENCH  LITERATURE  FROM  1795  TO  OUR  . 


1968. 


HAYOEN  BOOK 


-  TEICHMANN,  FREDERICK  KURT 


FUNDAMENTALS  OF  AIRCRAFT  STRUCTURAL. 


HOLT  -  PARATORF,  ANGELA 

ENGLISH  DIALOGUES  FOR  FOREIGN  STUDE. 


1956. 


875 

500 

1000 

*95 

195 


875 

500 

idoo 

595 
195 


Figure  5  -  A  Purchase  Order  Ready  to  be  Mailed  to  the  Vendor 
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For  each  record  included  on  a  purchase  order,  two  cards  are  punched 
simultaneously.  If  a  record  consists  of  more  than  one  item,  such  as  in  the  case 
of  multiple  copies,  volumes,  or  parts  being  ordered,  then  two  cards  are 
punched  for  each  physical  item  being  ordered.  These  "notify  cards,"  as  they 
are  called,  are  used  in  later  steps  of  processing  after  the  materials  are  received, 
described  below.  Figure  6  shows  a  punched  "notify  card." 

After  the  purchase  orders  are  printed,  all  records  on  the  permanent  tape 
with  a  status  of  "on  order,"  "cancelled,"  or  "received"  since  the  last  printing 
of  the  book  catalog  are  pulled  out,  sorted  alphabetically  by  author,  then  by 
title  within  author,  and  a  new  and  updated  "on  order"  list  is  printed  weekly. 
Figure  7  shows  a  page  from  an  "on  order"  list. 

Receiving  New  Materials 

When  invoices  and  materials  are  received  from  vendors,  the  two  "notify 
cards"  for  all  items  listed  on  the  invoices  are  pulled  from  the  "notify  card" 
file,  which  previously  has  been  arranged  by  title  behind  the  order  dates.  The 
actual  list  prices  as  indicated  on  the  invoices,  the  discounted  prices  (including 
any  pro-rated  transportation  or  handling  charges)  per  item  or  copy,  and  the 
dates  of  receipt  of  the  material  are  marked  with  an  electromagnetic  pencil  in 
the  respective  bubble-columns  of  one  copy  of  the  set. 

The  marked  copies  of  the  "notify  cards"  are  batched  and  sent  to  the 
computer  center  once  a  week  for  further  processing,  and  the  unmarked  second 
copies  are  inserted  in  their  matching  items  for  identification  purposes  to  await 
the  results  of  that  further  processing,  described  below. 

Preparation  of  Materials 

The  marked  copies  of  the  "notify  cards"  are  sent  to  the  computer 
center  and  the  new  information  is  punched  into  the  cards  by  the  reproducer 
from  the  mark-sensing.  By  processing  the  "notify  cards"  for  received  items 
against  the  master  tape,  several  actions  are  triggered:  1)  the  status  of  the 
record  for  each  received  item  is  changed  from  "on  order"  to  "received"; 
2)  the  information  necessary  to  update  the  budget  report  is  transferred  from  the 
"notify  cards"  to  the  tape  records;  and  3)  for  each  newly-received  item,  one 
spine  label  and  one  pocket  label  are  printed  and  one  machine-readable  book 
master  or  circulation  card  is  punched. 

As  soon  as  the  "notify  cards"  are  sent  to  the  computer  center  for 
further  processing,  pockets  are  pasted  in  the  new  material,  except  those 
designated  as  reference,  and  all  are  property  stamped.  The  materials  are  kept 
on  the  same  incoming  truck  if  possible  to  await  the  printing  of  the  labels  and 
the  punching  of  the  circulation  cards. 

After  these  materials  are  sent  to  the  library,  the  labels  are  applied,  the 
book  master  cards  are  inserted  in  the  pockets,  and  one  final  check  is  made 
before  the  finished  products  are  sent  to  the  circulation  departments  of  the 
campus  libraries.  Figure  8  illustrates  a  spine  and  pocket  label  and  a  book 
master  card. 
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TARRANT  COUNTY  JUNIOR  COLLEGE  DISTRICT 
ON  ORDER  LIST 
APRIL  7,  1969 


•WRIGHT.  JAMES  ARLINGTON 

SHALL  WE  GATHER  AT  THE  RIVER.  POEMS 

MESLEYAN  UNIV  PR      1968 
RS3545.R58S5  01  00400  1105  00441 


SE 
3/10/69  016735 


*WRI;GHT.  NATHAN 
READY  TO  RIOT 

HOLT 
HN80UN685W74 


1968 

01  00495  1815  00441 


SB 
3/24/69  017030 


•WRtSTON,  HENRY  MERRITT 

ACADEMIC  PROCESSION*  REFLECTIONS  OF  A  COLLEGE  PRES 

COLUMBIA  UNIV  PRESS   1959  MB 

LB2331.W7  01  00500  2105  04870   2/17/69  210574 


•WUQRINEN.  JOHN  HENRY 
SCANDINAVIA 

PRENTICE 
OL46.'W8. 


1965 

01  00495  2105  04870 


ME 
2/17/69  210573 


•HYLDER,  ROBERT  C 

WRITING  PRACTICAL  ENGLISH 

MACMILLAN 
PE1408.W87 


1966 

01  00225  2105  04870 


NE 
2/17/69  210572 


•WYNAR,  BOHDAN  S 

LS      LIBRARIES  UNLIMITED 
2689JW9 


1968         REF 

01  00500  1105  00441 


SE 
9/30/68  014197 


•WYTRWAL,  JOSEPH  ANTHONY 

AMERICANS  POLISH  HERITAGE.  A  SOCIAL  HISTORY  OF  THE 

DETROIT  ENDURANCE  PR  1961  NE 

E184JP7W9  01  00650  2105  04870   3/31/69  211280 


•YOUNG*  JOHN  ZACHARY 
LIFE  OF  MAMMALS 

OXFORD  UNIV  PRESS 
QL703.Y6 


1957 

01  01680  2105  0487C 


NE 
2/17/69  210571 


•  YOUNG.     LOUISE    B 
POPULATION    »* 


HB851 


Figure  7  —  A  Page  from  the  Weekly  "On  Order"  List 


Lists  of  Orders  Outstanding  Over  Ninety  Days 

At  the  end  of  each  month,  a  program  is  run  which  prints  lists  of  items 
outstanding  with  each  vendor  for  over  ninety  days.  Each  list,  which  is  printed 
on  stock  paper,  has  a  short  explanatory  note  requesting  shipment,  a  report,  or 
cancellation  on  each  item.  A  code  is  added  to  each  tape  record  listed  to 
indicate  that  a  report  to  the  vendor  has  been  sent;  an  item  is  listed  only  once 
on  such  a  list. 


TARRANT  COUNTY  JUNIOR  COLLEGE  DISTRICT 


127 


1 

e 

(O 

42 

3 

o 

b 

!—  I 

O 

!*• 

l_ 

NO 

0 

O^ 

M 

1-4 

CTJ 

NO 

c. 

O 

o 

•  1—  1 

^  PN» 

CO 

m  O 

•0 

Cs)    O^ 

c 

X  0 

cd 

-3  <N 

42 

JD 

o 

£ 

e 

<u 

e 

'& 

o 

1 
oo 

(*• 

1) 

NO 
1—  I 

ib 

sO 

ro 

X 

128 


JAMES  B.  CORBIN 


o 

o, 

oo 
v 

op 

£ 


TARRANT  COUNTY  JUNIOR  COLLEGE  DISTRICT  129 

Analysis  of  Vendor  Delivery  Times  and  Discounts 

A  second  major  and  highly  useful  report  in  conjunction  with  ordering  is 
the  analysis  of  vendor  delivery  times  and  discounts.  Run  once  a  semester,  this 
study  provides  an  analysis  of  the  shortest,  average,  and  longest  lapsed  time  of 
delivery  for  all  material  ordered  from  each  vendor  and  the  smallest,  average, 
and  largest  discounts  received  from  each  vendor. 

The  Budget  Reports 

The  monthy  budget  report  provides  each  of  the  library  staffs  and  the 
director  of  libraries  with  a  monthly  summary  of  activities  in  each  fund  allo- 
cated for  the  purchase  of  library  materials.  In  addition,  this  report  informs  the 
department  heads  on  each  campus  of  the  status  of  their  allocated  funds. 

Not  only  does  this  report  indicate  the  usual  budgeted  amounts,  orders 
outstanding,  paid  year-to-date,  and  free  balances  for  each  departmental  alloca- 
tion, but  also  appended  is  a  summary  listing  of  all  materials  on  order  against 
each  fund  but  unreceived  and  a  summary  listing  of  all  materials  received 
during  the  month  against  each  fund.  This  includes  the  total  volumes  and  titles 
outstanding  for  each  fund  and  the  total  volumes  and  titles  received  for  each 
fund  during  the  month.  Such  a  report  keeps  the  librarian,  the  department 
heads,  and  the  other  faculty  members  precisely  informed  as  to  all  activities 
concerning  the  book  funds. 

The  Book  Catalogs 

The  most  complex,  time-consuming,  and  expensive  phase  of  our  program 
is  the  one  which  generates  the  routines  which  prepare  and  print  our  book 
catalogs.  All  records  in  the  tape  file  with  a  "received"  status  code  are  included 
in  these  listings  which  are  in  four  separate  parts:  author  catalog,  title  catalog, 
subject  catalog,  and  classed  catalog.  One  set  of  listings  serves  all  campus 
libraries,  with  codes  indicating  inclusion  of  titles  on  particular  campuses. 
Figure  9  shows  samples  from  the  author,  title,  ana  subject  catalogs. 

An  annual,  cumulative  set  of  catalogs  is  printed  each  summer,  with 
cumulative  supplements  prepared  every  six  to  eight  weeks  between  the  annual 
printings.  Items  received  since  the  last  annual  or  supplementary  set  of  catalogs 
remain  listed  on  the  "on  order"  list  but  with  "received"  and  the  date  of 
receipt  printed  beside  each  item.  When  the  next  set  of  catalogs  is  printed,  all 
received  items  then  are  dropped  from  the  "on  order"  list  entirely  and 
included  in  the  catalog  listings. 

While  better  and  less  expensive  methods  of  production  are  being 
explored  and  considered,  the  last  annual  cumulation  of  the  catalogs  was 
printed  on  blank  paper  by  the  line  printer.  These  sheets  then  were  pasted  in 
blocks  of  four  pages,  photographed,  reduced  in  size,  and  then  offset.  All 
supplements  are  either  offset  without  reduction  or  simply  printed  on  stock 
paper  by  the  line  printer. 

In  August  1968,  approximately  400  copies  of  each  author,  title,  and 
subject  catalog  were  printed,  offset,  and  bound.  A  set  of  catalogs  was  placed 
in  the  office  of  each  faculty  member  on  each  campus,  and  copies  were  placed 
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liberally  throughout  each  library.  An  earlier  attempt  to  sell  copies  of  the 
catalogs  in  our  bookstores  met  with  failure.  Only  one  original  and  several 
carbons  of  the  classed  catalog  are  printed,  mainly  for  the  staffs  use. 

As  previously  noted,  we  have  not  as  yet  found  a  satisfactory  method  of 
producing  the  book  catalogs.  Also,  we  have  not  as  yet  settled  finally  on  the 
time  intervals  for  the  supplements.  Hopefully,  a  print  shop  which  is  being 
established  on  one  of  our  campuses  will  solve  the  printing  problem.  In  any 
event,  I  should  hasten  to  point  out  that  while  we  have  difficulties  in  produc- 
ing the  catalogs,  we  have  no  plan  or  desire  to  change  to  a  card  catalog.  The 
technical  problems  will  be  worked  out  as  soon  as  we  gain  more  experience 
and  as  the  libraries  grow. 


*ADAMS>  JAMES  DONALD 

MAGIC  AH'j  MYSTtKY  UF 
PE1574.A3  NORTHEAST 


.  HULT  1963 


*AOAMS>  JAMES  FREDERICK 

UNDERSTATING  ADQLESCFNCE*  CURRENT  DEVELOPMENTS  IN  ADOLESCENT 
PSYCHOLOGY.  ALLY*  19<i? 
BF724.A25  S'lUTH 


•ADAMS,  JAMES  TRUSLOW 

MARCH  OF  DfcMntRACY,  A  HISTORY  OF  THE  UNITFO  STATES.  SCRIBNER  1965 
E178.A29->2 


•ADAMS;  JAMES  TRUSLUW 
MARCH  OF 


pn*KF.P 
Z58O.«r>l 


1966. 

REFERE'CF.  SQI'TH 

0*EISF.R,  HUP  BITTER  PATRIOT. 
•SHAPIPQ,  CHARLES 

SHUTHFRv  ILL  I'NIV  PR  1962  (CROSSCURRENTS,  MODERN  CRITI8UES) 

PS3*07.''!>'i£'1  J    S'TUTH 

THIS    DIFFICJIT    PiJTVlDUAL, 
FUSTACF    CLARENCE 
FLEET    lOfti 
PS3531  .fi8?Z75^    SOUTH 


5N  6UIDI/  JUNE  1966-JUNf  1*68 
AAHPER  1966 

GV1007,A1A<.  1966-68  NORTHEAST 


BAGEHOT/  WALTER 


•ST  JDHN-STEVA5,  NORMAN 

-ALTER  BAGEHOT,  LONGMANS  1963  (WRITERS  AND  THEIR  WORK/  NO  160) 
HB103.B2S3  SOUTH/  NORTHEAST 

•  •••••••••_•••«»•••*•••_*••••••••••••  —  •••••••«••«»•••••  •^••••••  —  »»••« 

BAHAMAS  -  DESCRIPTION  AND  TRAVEL 


•SCHOEPF/  JOHANN  OAVIO 

TRAVELS  IN  THE  CONFEDERATION,  1783-178*.  8ERCMAN  1968  2V 
E164.S38  1968  NORTHEAST 


Figure  9  -  Sample  Pages  from  the  Author,  Title,  and  Subject  Catalogs 
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The  Circulation  of  Materials 

Last  but  not  least  by  any  means  are  the  programs  for  the  circulation 
system.  The  system  used  in  all  libraries  of  the  district  is  the  Standard  Register 
Source  Record  Punch,  Model  1730,  which  is  a  desk-top  electric  data  collection 
machine  utilizing  the  same  basic  principle  as  IBM's  357  Data  Collection 
System. 

When  a  machine-readable  book  master  or  circulation  card,  prepared 
automatically  by  the  computer  during  the  receiving  processes  (see  Figure  8), 
and  a  machine-readable  borrower's  identification  badge  are  inserted  into  the 
machine,  information  from  the  book  master  card  and  the  badge  are  trans- 
ferred to  a  "ZIPCARD"  set,  which  is  inserted  into  the  machine  at  the  same 
time.  The  date-due  is  entered  into  the  system  by  a  changeable  slide  within  the 
machine,  or,  by  keying  in  a  variable  date  from  a  keyboard. 

The  badge  is  returned  to  the  borrower,  and  the  book  master  card  to  the 
pocket.  The  "ZIPCARD"  set  is  torn  apart,  and  the  discharge  card  part  of  the 
set  is  inserted  on  top  of  the  book  master  card  in  the  pocket  of  the  material. 
The  other  part  of  the  "ZIPCARD"  set,  the  charge  card,  is  placed  in  a  stack  to 
await  the  end  of  the  day,  when  all  new  charges  are  sent  to  the  computer 
center  to  be  included  on  the  circulation  tape. 

When  an  item  is  returned,  the  discharge  card  in  the  pocket  is  simply 
removed  from  the  pocket,  the  book  returned  to  the  shelf,  and  the  discharge 
card  is  placed  in  a  stack  and  sent  to  the  computer  center  at  the  end  of  each 
day,  where  the  circulation  tape  is  updated. 

A  separate  daily  list  of  all  materials  in  circulation  is  prepared  for  each 
campus  library.  Each  library's  list  consists  of  four  parts:  a  list  of  all  materials 
in  circulation  arranged  by  LC  classification  number;  a  list  of  all  materials  in 
circulation  arranged  by  borrowers'  Social  Security  numbers;  a  list  of  all 
materials  placed  on  reserve;  and  statistics  for  the  day's  charges  and  discharges 
by  type  of  borrower,  such  as  student,  faculty,  staff,  and  so  on.  Figure  10  is  a 
sample  page  from  a  daily  circulation  list  arranged  by  LC  classification. 

As  soon  as  an  item  becomes  overdue  an  asterisk  is  printed  beside  the 
record  on  the  circulation  list.  Once  a  week  the  computer  prints  notices  for  all 
items  overdue,  except  for  those  charged  out  to  faculty  members.  These  over- 
due notices  are  on  forms  ready  to  be  torn  apart,  placed  in  envelopes,  and 
mailed.  As  soon  as  our  current  supply  of  forms  is  exhausted,  we  will  begin 
using  a  data-mailer  for  the  notice.  Figure  11  is  an  overdue  notice  printed  out 
and  ready  to  be  mailed  to  a  student.  At  the  end  of  each  semester,  all 
materials  charged  out  to  each  faculty  member  are  printed  on  individual  lists  as 
a  reminder  to  either  return  or  renew  all  items  before  the  new  semester  begins. 

Plans  are  being  made  to  block  a  student's  registration  for  a  new  semester 
if  he  owes  any  fines  or  if  he  has  any  unreturned  books  charged  to  his  badge, 
but  at  present  we  only  can  provide  the  registrar  with  a  list  of  delinquent 
borrowers  to  be  manually  checked  as  students  register. 

Statistics  of  circulation  activities  are  cumulated  and  a  special  study  is 
prepared  at  the  end  of  each  semester  to  indicate  the  frequency  of  circulation 
of  every  item  circulated.  An  analysis  of  the  types  of  borrowers  for  circulated 
materials  during  each  semester  is  planned  which,  we  hope,  will  give  us  some 
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indication  as  to  what  students  is  which  subject  areas  use  the  library  the  most. 
Our  first  analysis  from  this  program  probably  will  not  be  ready  until  the  end 
of  the  fall  1969  semester. 

PROBLEMS  ENCOUNTERED  IN  THE  PROGRAM 

The  problems  we  have  encountered  with  our  system  have  ranged  from 
the  usual  too  little  time,  experience,  personnel,  programming  and  computer 
time  to  delays  in  construction  of  facilities.  On  the  whole,  however,  we  feel  we 
have  accomplished  much  and  have  learned  still  more  in  this  short  period. 
Perhaps  we  moved  too  fast— perhaps  we  moved  too  slow.  We  certainly  have 
made  plenty  of  mistakes. 
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Figure  1 0  —  A  Sample  Page  from  a  Daily  Circulation  List 
Arranged  by  LC  Classification 
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One  specific  problem  encountered  in  the  program  has  been  the 
monitoring  of  the  flow  of  data  through  the  system.  Since  the  records  are 
constantly  being  moved  about  as  new  records  are  merged  into  and  cancelled 
from  the  tapes,  we  have  found  it  difficult  at  times  to  be  absolutely  certain 
that  all  the  correct  records  remain  in  the  proper  form  on  the  tapes.  While  we 
have  attempted  to  provide  all  the  safeguards  possible,  records  do  at  times 
mysteriously  disappear  into  whatever  form  of  electronic  limbo  there  is,  some- 
times to  reappear  at  the  right  or  wrong  times  like  unidentified  flying  objects. 

Since  we  are  a  junior  college  system  providing  little  research  material, 
well  over  99  percent  of  all  our  acquisitions  can  be  bibilographically  located 
and  pre-cataloged  before  ordering.  The  other  less  than  1  percent  give  us  trouble. 

Staffing  has  also  been  a  problem.  Because  we  began  operation  with  an 
automated  system,  our  administration  has  felt  that  fewer  people  were  needed. 
Consequently,  even  for  an  automated  library,  we  are  understaffed. 

FUTURE  PLANS 

Generally  we  know  what  we  want  to  do  in  our  automation  program  and 
how  we  plan  to  accomplish  our  goals.  The  framework  of  the  program  is 
flexible  enough  that  new  programs  can  be  added  or  old  programs  removed  as 
we  see  fit.  Alterations  to  implemented  programs  are  possible  with  a  minimum 
amount  of  difficulty. 

As  the  staff  gains  experience  and  confidence  and  as  more  planning, 
thought,  and  experimentation  are  done,  the  machine  services  hopefully  will  be 
expanded  to  include  on-line  terminals  of  some  sort.  We  fully  expect  to  take 
advantage  of  the  MARC  tapes  from  the  Library  of  Congress  as  soon  as  we 
feasibly  can. 

Should  we  be  legally  able  later  on,  our  system  can  be  expanded  to 
include  other  junior  college  or  public  libraries  in  the  region,  should  others  care 
to  share  our  facilities  and  machine  services. 

It  only  can  be  stated  at  this  particular  point  in  our  development  that 
machines  will  be  used  in  every  conceivable  manner  in  the  future  to  improve 
our  services  and  to  serve  our  staffs,  students,  and  faculties. 


Calvin  J.  Boyer 

Director  of  Libraries 

and 

Jack  Frost 

Supervisor  of  Data  Processing 

Midwestern  University 

Wichita  Falls,  Texas 


ON-LINE  CIRCULATION  CONTROL- 
MIDWESTERN  UNIVERSITY  LIBRARY'S  SYSTEM 
USING  AN  IBM  1401  COMPUTER 
IN  A  "TIME-SHARING"  MODE 

In  November  1967,  an  on-line  automated  circulation  control  system  was 
put  into  operation  in  the  Moffett  Library  at  Midwestern  University.  The 
system  is  designed  to  charge,  discharge,  and  list  all  materials  in  circulation,  as 
well  as  to  detect  overdue  materials,  prepare  notices  and  compute  fines.  The 
uniqueness  of  the  system  lies  principally  in  the  configuration  of  the  equipment 
and  the  programming  to  provide  for  on-line  operation.  (See  Figures  1  and  2). 
Through  a  program  interrupt  capability,  an  IBM  1030  Data  Collection  System 
(IBM  1031  input  station,  and  IBM  1033  printer)  is  linked  with  a  second 
generation  computer  (140 1-1 6K)  in  an  on-line  mode  that  allows  other  depart- 
ments on  campus  to  use  the  computer  when  it  is  not  in  actual  use  by  the 
Library  (See  Appendix  A). 

Although  other  libraries  have  developed  on-line  circulation  systems,  few, 
if  any,  have  done  so  without  employing  either  a  third  generation  computer  or 
a  computer  to  be  used  solely  by  the  library.  That  a  system  can  be  designed  to 
provide  an  on-line  capacity  for  nearly  simultaneous  data  processing  for  more 
than  one  department  using  a  second  generation  computer  is  additionally  note- 
worthy in  view  of  the  already  widespread  availability  of  the  IBM  1400  series 
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Figure  1 
SYSTEM  CONFIGURATION 

lUOl  (l6K)  Data  Processiag  System 

lU02  Card  Read  Punch 

1U06  Storage 

1311-OOU  Disk  Storage  Drive 

1311-002  Disk  Storage  Drive  (2) 

ll*03  Printer 

1^09  Console  Auxiliary 

1026  Transmission  Control  Unit 

1031  Input  Station 

1033  Printer 

The  1^01  has  the  following  features: 

Advanced  programming 

Disk  storage  drive  adapter 

Expanded  print  edit 

High-low-equal  compare 

Print  control 

Punch  feed  read  control 

Space  suppression 

Sense  switches 

Approximately  U500  positions  of  core  are  reserved  for  library  use, 

and  one  disk  drive  is  allocated  to  the  library  for  circulation 

control. 
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Figure  2 
COKE  MAP 


1.  Library  Monitor  150 


2.  Disk  IOCS  routines  U37 


3.  Dump  routine 332 


U.  Library  -processing  routines    3576 


Total  Library 


5.  Background  programs          11505 
(all  10  handled  by  monitor) 


Total  Capacity      16000 
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computer.  Experience  with  the  Midwestern  University  installation  indicates 
that  it  is  not  only  possible  for  a  relatively  inexpensive  computer  such  as  the 
IBM  1401  to  handle  library  circulation  transactions  on-line  in  "real-time"  but 
that  it  can  also  perform  other  administrative  and  record-keeping  work  virtually 
simultaneously. 

Multi-programming  techniques,  which  are  normally  considered  too 
sophisticated  for  computing  hardware  of  this  generation,  permit  the  Mid- 
western University  Library,  which  could  not  afford  a  computer  of  its  own,  to 
use  this  computer  just  as  if  it  were  wholly  dedicated  to  the  Library,  and 
without  severely  affecting  the  machine's  productivity  in  handling  other  work. 
The  system  design  assures  the  currency  of  library  records,  facilitates  services, 
and  makes  possible  circulation  control  activities  which  are  not  economically 
feasible  with  manual  or  off-line  automated  systems. 

The  system  accurately  identifies  the  patron  and  charged-out  materials, 
provides  for  variable  loan  periods,  simplifies  circulation  procedures,  provides 
data  on  loaned  material,  detects  overdue  books  and  prepares  appropriate  over- 
due notices,  provides  a  system  of  holds,  obtains  a  daily  count  of  charged-out 
materials,  provides  classification  data  on  books  used,  and  provides  manage- 
ment reports.  This  new  Midwestern  installation  is  able  to  do  all  of  these 
things,  plus  others,  more  efficiently  and  more  simply. 

This  application  of  the  1030  Data  Collection  System,  coupled  in  an 
on-line  capacity  with  the  1401  computer  in  a  remote  facility,  offers  these 
additional,  particularly  desirable  features: 

1.  The  loan  period  is  coded  into  each  bookcard;  this  eliminates 
the  need  for  the  multiple  date-due  cartridges  employed  in  the  IBM  357 
system. 

2.  The  on-line  capacity  provides  the  ability  to  override  the  loan 
period   in   the   bookcard   by   coding   the   borrower's  badge   either   to 
lengthen  (for  faculty),  or  to  shorten  (for  area  users)  the  loan  period. 

3.  The   on-line   capacity   in  this  system  provides  the  ability  to 
automatically  withhold  materials  from  a  delinquent  borrower  until  over- 
due materials  are  returned,  fines  paid,  or  an  override  command  given. 

4.  Reserve   books  are   automatically   returned   to   reserve   status 
when  they  are  discharged.  They  then  appear  on  the  daily  circulation 
print-out  as  charged  to  reserve.  (Though  the  library  does  not  presently 
have  any  books  on  hourly  reserve,  this  status  would  be  accessible  by  a 
slight   modification   of  the   system,   and  by  the  addition  of  a  clock 
mechanism). 

5.  When  necessary  or  convenient  the  library  can  determine  who 
has  what  items  checked  out  and  whether  they  are  overdue  by  means  of 
an  on-line  inquiry  feature. 

6.  In  capturing  more  data  in  each  bookcard  than  off-line  systems 
will   permit,   this   system   produces   more    intelligible   records   without 
accessing  a  master  record  file  (see  Figure  3). 

In  addition  to  these  features,  the  experience  of  Moffett  Library  in  the 
application  of  on-line  automation  techniques  to  library  circulation  control 
underscores  five  additional  aspects: 
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1.  If  a  non-dedicated  second  generation  computer  can  serve  the 
library  in  an  on-line  capacity,  the  same  machine  can  serve  other  depart- 
ments on  campus  as  well.  (The  implications  of  this  statement  certainly 
might  prolong  the  useful  life  of  the  second  generation  computer  far 
beyond  present  proposed  utilization.) 

2.  A  highly  desirable  level  of  sophisticated  computing  operations 
(on-line  status)  is  possible  with  a  second  generation  computer. 

3.  On-line    systems   are    no    more   difficult   to   implement   than 
off-line  systems,  and  in  fact,  in  some  respects,  on-line  systems  require 
simpler  programs. 

4.  In   converting   present   manual  operations  to  automated  pro- 
cedures, it  is  not  necessary  and,  indeed,  it  may  even  be  undesirable,  to 
convert  to  off-line  status  in  preparation  for  full  conversion  to  an  on-line 
operation.  (Some  installations  will  find  that  it  would  have  been  better 
not  to  convert  to  a  semi-automated  system,  but  rather  to  wait  until  it 
would  have  been  possible  to  convert  to  a  full  on-line  operation.) 

5.  Efficient    manual    and    automated    off-line    systems    cannot 
duplicate  advantages  inherent  in  an  on-line  system,  either  in  circulation 
control,  or  in  other  areas  within  the  library. 

Limited  funding,  an  all-too-common  problem  for  most  libraries,  has 
often  made  it  impractical  to  automate  circulation  and  associated  procedures. 
Moffett  Library,  experiencing  increasing  levels  of  circulation,  faced  this 
problem  in  1967.  At  that  time,  a  study  of  automated  circulation  control 
systems  was  begun,  and  it  was  concluded  that  an  on-line  system  permitting 
continual  instantaneous  communication  between  the  Library's  circulation  desk 
and  a  computer  would  be  most  desirable. 
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This  conclusion,  however,  posed  a  particular  problem,  since  the  only 
computer  available  in  the  University  was  a  second  generation  IBM  1401-16K, 
which  had  been  given  to  the  University  by  two  benefactors.  The  computer 
was  being  used  to  process  administrative  work  for  the  University,  and  it  was 
thought  incapable  of  handling  library  work  on-line  in  "real-time"  while  doing 
other  work  required,  as  do  the  larger,  and  consequently  more  expensive 
"time-sharing"  or  "multiprogrammed"  third  generation  computers. 

Ideally,  the  library  might  have  wished  to  purchase  its  own  computer, 
which  would  then  have  been  a  machine  dedicated  to  Library  operations;  how- 
ever, the  shortage  of  Library  funds  proved  to  be  a  deterrent  to  this  solution. 

The  Library  thus  had  a  choice  of  abandoning  its  hopes  for  an  on-line 
circulation  control  system,  or  developing  programming  for  its  existing  1401  so 
that  it  would  be  on  continuous  call  to  the  Library,  while  at  the  same  time 
handling  administrative  and  other  routines.  Though  no  one  else  was  known  to 
have  accomplished  this  with  a  1401,  the  decision  was  made  to  develop  such  a 
dual  usage  system.  Those  who  examined  the  situation  concurred  that  it  was  at 
least  theoretically  possible  to  accomplish  this. 

Once  the  decision  was  made  to  install  the  circulation  control  system, 
less  than  eight  weeks  were  required  to  implement  the  system  design.  As 
previously  indicated,  the  system  consists  of  a  remote  1030  data  collection 
system  in  the  library,  which  is  linked  to  a  1026  transmission  control  unit  that 
operates  under  the  control  of  the  1401  in  a  remote  location  in  the  Univer- 
sity's data  processing  center.  The  system  essentially  revolves  around  a 
computer-maintained  "master  magnetic  disk"  record  of  circulation  trans- 
actions, including  current  data  on  location  of  volumes,  fines  owed,  and  past 
due  or  other  irregular  situations.  One  of  three  1311  magnetic  disk  drives 
available  in  the  computer  center  is  dedicated  to  the  library  circulation  control 
system. 

Briefly,  as  the  system  does  administrative  work  for  the  University  in  the 
data  processing  center,  it  is  on  continuous  "call"  to  the  Library  during  the 
eighty-five  hours  of  the  Library's  operation  each  week. 

Whenever  a  library  assistant  wishes  to  transmit  a  transaction— for 
example,  a  book  to  be  charged  out— he  simply  transmits  the  required  data,  as 
recorded  in  a  machine-readable  bookcard  and  a  student  ID  badge  encoded 
with  the  borrower's  identification  number,  to  the  data  processing  center,  via 
the  1031  input  terminal  which  reads  from  the  card  and  badge  and  transmits 
the  data  via  an  underground  cable  to  the  1026  transmission  control. 

At  the  data  processing  center,  the  computer  is  constantly  monitoring  the 
transmission  control  unit  to  determine  whether  data  are  being  transmitted 
from  the  Library.  If  data  are  being  transmitted,  the  computer  momentarily 
stops  whatever  job  it  is  doing  and  processes  the  library  transaction,  thus 
updating  effective  library  records  on  the  magnetic  disk  drive.  The  1401  then 
sends  back,  via  the  1026  transmission  control,  the  particular  message  required 
to  the  output  station  (the  1033  printer)  at  the  Library.  Having  completed  this 
transaction,  the  computer  picks  up  where  it  had  left  off  when  the  trans- 
mission from  the  Library  was  received. 

At  the  library  data  collection  unit,  the  average  "turn-around"  time  for  a 
complete  transaction  is  seven  seconds.  However,  the  computer  is  interrupted 
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for  only  about  a  second— a  time  so  short  that  it  appears  to  the  observer  that 
there  has  been  no  interruption  at  all. 

Programming  for  the  system  proved  to  be  actually  simpler  than  the 
programming  required  for  most  off-line  operations.  The  program,  written  in  an 
IBM  Autocoder  language,  is  essentially  a  "monitor"  which  remains  loaded  in 
core  and  which  is  constantly  polling  the  transmission  control  unit  for 
incoming  data  from  the  Library.  Upon  recognition  of  an  input  signal,  the 
computer  executes,  under  the  supervision  of  the  monitor,  an  instruction  to 
halt  momentarily  the  job  in  process,  and  switches  to  the  portion  of  the  library 
program  required  to  handle  the  particular  type  of  library  transaction  being 
received.  Once  the  transaction  is  completed,  the  monitor  turns  the  control 
back  to  the  original  program  which  was  interrupted  by  the  initial  receipt  of  a 
library  transmission.  IBM's  standard  DIGS  (Disk  Input-Output  System) 
programming  is  used  to  access  the  disk  file. 

When  a  borrower  wishes  to  charge  materials  and  the  information  is  sent 
via  the  1031  input  station  to  the  computer,  the  computer  first  checks  to 
determine  if  there  is  a  hold  on  the  title  and  then  ascertains  the  status  of  the 
borrower.  If  the  borrower  currently  has  past  due  materials  or  owes  an  unpaid 
fine,  the  1401  transmits  a  message  to  this  effect  (see  Figure  4),  and  will  not 
charge  out  another  book  until  the  delinquent  account  has  been  cleared,  or  the 
machine  is  instructed  to  make  the  charge  by  an  override  command. 

In  this  system,  the  loan  period  is  coded  into  each  bookcard.  The  on-line 
capacity,  however,  provides  the  ability  to  override  the  loan  period  specified  in 
the  book,  in  accord  with  a  specific  override  command  encoded  in  the 
borrower's  badge,  either  to  lengthen  the  loan  period  (for  faculty)  or  to 
shorten  it  (for  area  users  not  enrolled  in  the  University).  In  fact,  encoding 
the  borrower's  badge  can  prohibit  certain  borrowers  from  obtaining  materials 
from  the  Library  through  the  system,  unless  an  override  command  is 
given— for  example,  reserve  material  will  not,  under  normal  circumstances, 
circulate  to  area  users.  It  will  be  noted  that  no  intervention  of  the  library 
assistant  is  needed  to  lengthen  or  shorten  loan  periods,  nor  to  check  the  status 
of  the  borrower,  as  each  process  is  an  automatic  one  with  each  transaction  by 
pre-programmed  instructions  to  the  computer. 

If  the  status  of  the  borrower  is  clear,  once  the  length  of  the  loan  period 
has  been  determined  by  the  machine,  a  notice  is  prepared  by  the  1033  type- 
writer which  is,  in  effect,  a  date-due  slip.  The  slip  contains  the  accession 
number  for  verification  at  the  door  checkpoint,  the  borrower's  number,  and 
the  date  due.  This  slip,  together  with  the  bookcard,  is  returned  to  the  book 
pocket. 

Discharging  procedures  are  nearly  identical,  except  that  the  borrower 
need  not  be  present.  The  information  to  discharge  a  book  is  fed  via  the  data 
collection  system  to  the  computer,  and  the  record  is  erased  from  the 
borrower's  responsibility  unless  a  delinquent  condition  is  noted.  If  the 
returned  book  is  overdue,  this  fact  will  be  noted  by  the  computer,  the  fine 
calculated,  and  the  charge  erased  from  the  student's  responsibility,  though  the 
fine  will  remain  until  it  is  separately  erased. 

The  on-line  status  of  the  circulation  control  system  also  permits 
immediate  inquiry  to  determine  what  a  particular  borrower  may  have  charged 
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Examples  of  inquiry  responses 

A.  Automatic  inquiry  performed  when  book  is  attempted  to  be  checked  out. 

B.  Typical  patron  inquiry. 

C.  No  address  notice.  (At  this  point,  assistant  has  patron  fill  out  address  card.) 

D.  Fine-paid-for  notice. 

E .  Inquiry  notice — nothing  out  or  overdue. 


Figure  4  —  Transaction  Slips  from  Output  Terminal 
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to  him,  whether  the  material  is  overdue  or  not,  i.e.,  the  system  can  report  all 
items  charged  to  a  borrower  at  any  given  time  (see  Figure  4). 

Also,  the  on-line  status  permits  a  specific  title  to  be  charged  and  dis- 
charged any  number  of  times  each  day,  and  only  the  latest  record  of 
possession  of  the  piece  will  be  retained  by  the  computer,  with  earlier  charges 
being  destroyed  as  the  latest  charge  is  recorded.  This  is  particularly  beneficial, 
for  a  number  of  off-line  automated  circulation  systems  have  found  it  to  be 
difficult  to  keep  track  of  a  piece  which  is  charged  and  discharged  several  times 
during  a  day,  before  the  record  is  updated. 

Certain  daily  reports  are  generated  by  batch  mode  processing,  at  the  end 
of  each  day's  activity,  a  listing  showing  all  transactions  (basically  an  audit 
statement)  is  produced.  In  addition  to  the  audit  statement,  a  complete  circula- 
tion listing  indicating  all  volumes  in  circulation  is  produced,  with  volumes 
arranged  in  call  number  sequence.  In  addition  to  the  call  number,  the 
accession  number,  short  author-title  statement  (43  characters—  variable-length 
author  statement),  the  borrower's  identification  number,  and  the  date  due  are 
included.  A  third  listing  arranged  by  borrower  is  also  produced,  indicating  all 
books  overdue  and  all  fines  owed  by  each  borrower.  Management  reports 
prepared  daily  by  batch  mode  include  an  analytical  summary  of  the  number 
of  books  charged  to  faculty,  students,  staff,  and  area  users,  those  on  reserve, 
and  those  at  the  bindery.  Ready-to-mail  past  due  fine  notices  listing  the 
computer-calculated  fine  amounts  due  are  also  generated  by  off-line  batch 
processing. 

Of  the  many  systems  investigated  before  the  decision  to  automate  was 
finally  made,  Midwestern's  system  would  seem  to  involve  both  the  patron  and 
the  library  assistants  less  than  any  of  the  other  systems  analyzed.  The  many 
variables— status  and  eligibility  of  the  borrower,  the  length  of  loan  for  each 
title,  etc.— are  handled  entirely  by  the  machine,  systematically  and  con- 
sistently, and  numerous  interpretations  of  fines  due  that  incorporate  holiday 
periods  or  weekends,  are  handled  by  the  machine  with  no  student  inter- 
vention, other  than  insertion  of  needed  data  into  the  terminal.  With  the 
addition  of  a  cartridge  input  facility  on  the  data  input  terminal,  it  is  also 
possible  to  enter  a  borrower's  identification  number  through  a  cartridge. 

Though  the  installation  at  Midwestern  University  has  not  utilized  the 
potential  of  multiple  terminals  throughout  the  campus  in  branch  libraries  or 
other  facilities  connected  to  the  1401,  this  is  quite  conceivable.  Therefore, 
large  libraries  may  well  wish  to  consider  the  possibility  of  installing  an 
in-house  second  generation  computer  which  could  handle  circulation  control 
for  the  main  library  and  branch  libraries  in  an  on-line  status,  and  which  would 
at  the  same  time  be  quite  capable  of  handling  most  of  other  data  processing 
requirements,  except,  of  course,  those  reflecting  proposals  especially  geared  to 
third  generation  computers.  Such  systems  could  readily  include  other  on-line 
operations  (acquisitions,  serials,  etc.,  through  a  keyboard  input  station),  in 
addition  to  the  circulation  control  system. 


APPENDIX  A 
Programming  HOS  (Hybrid  Operating  System) 

The  Hybrid  Operating  System  is  designed  to  provide  for  a  low  core 
program  with  the  library  as  a  top  priority  programmed  interrupt.  It  supplies 
all  inputs  and  outputs  and  error  checking  of  the  disks,  printer-reader,  and 
punch  equipment.  It  is  also  designed  to  provide  continuity  between  the  three 
programs,  since  the  1401  is  constructed  to  run  only  one  program  at  a  time.  It 
also  provides  for  on-line  processing  of  the  1030  data  terminal  located  in  the 
library. 

The  MONITOR  Control  Program  uses  150  core  storage  positions.  The 
program  starts  with  "MONIN"  (a  symbolic  label  for  point  of  entry)  and  is 
instructed  to  save  the  address  just  branched  from,  for  later  use.  It  checks  the 
I/O  with  the  next  sequential  instruction  from  the  User  Program  and  stores  it 
in  the  "MONIO"  instruction  (MONIO  is  a  symbolic  label  for  a  four  position 
area  in  which  the  monitor  builds  an  I/O  and  branch  instruction).  "MONTOR" 
(MONTOR  is  a  symbolic  label  in  the  monitor  program  for  a  branch  to  the 
library  data  transmission  routine)  then  checks  the  data  terminal  in  the  library. 
If  the  data  terminal  is  busy  reading,  polling  (waiting)  or  transmitting,  it  is 
ignored  and  the  program  branches  to  test  the  switches.  If  the  data  terminal  is 
not  busy,  but  dead,  a  poll  list  is  sent  (asking  if  the  library  wants  on)  and  then 
branches  back  to  MONTOR.  If  the  data  terminal  is  not  dead  and  a  service 
request  is  being  transmitted  from  the  library,  the  library  data  are  processed 
immediately  and  the  appropriate  message  is  transmitted  back  to  the  library 
by  underground  telephone  cable.  MONTOR  is  executed  again  to  assure  the 
message  is  being  transmitted.  If  the  data  terminal  is  busy  the  program  will 
ignore  it  and  move  to  test  the  switches.  If  the  data  terminal  is  busy,  although 
not  dead,  and  there  is  no  service  request  and  no  bid  for  the  line,  then  there  is 
trouble,  and  the  program  branches  to  MONTOR  for  a  recheck. 

The  second  part  of  the  program  works  the  same  as  the  stop  button  on 
other  computers.  Since  the  1401  must  always  be  on  to  process  the  library,  the 
F  and  G  switches  are  used  as  a  waiting  place.  The  G  switch  is  tested  first.  If  it 
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is  reverse  from  its  last  status,  the  next  program  from  the  user  is  loaded.  If  the 
G  switch  has  not  been  reversed  but  the  F  switch  has,  the  program  waits  until 
the  F  switch  is  reversed  manually  and  then  continues.  This  switch  is  mainly 
for  the  operator's  convenience;  it  allows  him  to  stop  whenever  necessary. 

The  third  part  of  the  program  is  to  determine  what  the  I/O  is.  If  the 
I/O  type  is  disk,  then  the  instruction  is  to  read  and  write  disk.  If  the  I/O  is 
equal  to  F  (punch-read-feed)  then  the  punch-read-feed  is  set  up.  If  the  I/O  is 
not  one  of  the  above,  the  I/O  originally  stored  is  executed  and  control  is 
returned  to  the  user  program. 

If  the  I/O  is  the  user  program  is  a  no  op,  the  program  branches  back  to 
MONTOR  to  wait.  The  internal  F  switch  is  reversed  to  wait  if  the  I/O  is  not  a 
no  op.  (The  operator  has  pushed  start-reset-start  physically.)  Until  the  F 
switch  is  reversed  externally,  the  operation  is  waiting  and  then  it  goes  back 
through  the  program. 
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